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A. COMPUTER PROCESSING SUPPORT* 

James Kast, Luke Kraemer, BiXl Shelley, 
Susan Schwingendorf and Terry Phillips 


1. Introduction 
1,1 Background 


For the past twenty months, researchers at Purdue and Johnson Space 
Center has shared the Laboratory for Applications of Remote Sensing (LARS) 
computer facility as their primary data processing environment for 
research. The Computer Processing Support Task enables and supports 
this activity by: 

^providing access to a computer facility designed and implemented to 
support remote sensing research needs; 

^providing trainii in the use of the hardware and software facilities 
on the computer system; 

^providing consulting support to the remote users of the facility; 

^developing software supporting and enhancing the utility of the 
facility; 

* investigating, and promoting the potential benefits which may be 
derived when geographically dispersed research centers working on 
the same problem (researching remote sensing of agriculture) share 
a computational environment. 


*The work conducted under 3A, Computer Processing Support Task, is the product 
of a team effort at Purdue and JSC. Creating the environment needed to 
enable a large, moderately diverse set of users at JSC to receive responsive 
computer service from an installation 1100 mile distant (at Purdue) is a 
substantial task. I believe JSC and Purdue have been largely successful 
in sharing the LARS computational facility through some very hard work 
by people at both institutions. 

At JSC, I thank Ken Baker for his tireless collection and communication 
of user needs and his excellent representation of research computer 
requirements from JSC’s perspective. His many hours on the phone with me 
and others at LARS has greatly magnified our ability to provide good 
computer service. 
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1.2 Objectives 


The objective of the Computer Processing Support Task is to provide 
JSC and its associated research community with the environment necessary 
for the implementation of a shared data processing system for researching 
remote sensing of agriculture. 

The full implementation of a shared data processing environment 
(network or centralized facility) would provide the following potential 
benefits; 

*the opportunity to better mold geographically-dispersed research 
groups into a more informed and integrated research team; 

*A mechanism for efficient transfer of information between research 
centers, NASA, and other participating government agencies; 

*Faster, less redundant software development; 

*Faster transfer of newly developed analysis techniques and research 
results to and from participating research groups; 

^Concentration of systems programming, data acquisition, data 
base and certain computer services at a small number of locations 
(frequently one) . 

These potential benefits can accrue largely through the communication 
features accessible to all users of a shared system; the elimination of the 
need to re-program techniques to be compatible with several different 
operating systems, data storage schemes, etc.; and the commonality of 
available software utilities, operational procedures, data, etc. 


*Glen Prow of LEC has provided excellent hardware support, isolating and 
identifying problems in the communications hardware, training operations 
personnel, and suggesting and upgrading the JSC-LARS terminal system. 
Without his able assistance, JSC users might well be experiencing much 
more frequent down time on antiquated equipment. 

Pat Aucoln, Mike Pore and Don McGee have provided local user support and 
Don collated and communicated resource request allocations for JSC users. 
Pat has also enabled researchers at Purdue to make more complete use of 
EOD LARSYS by enhancing its abil ity to hamll o. LARSYS Version TTT formats. 
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1,3 Approach 

The Computer Processing Support Task has a very broad i^cope. The 
discussion of Subtask is organized under the headings of Hardware Components; 
Software Support; Data Management; System Access; Communications, Consulting 
and Training; and Administration. 

Over the past year, work funded through this task lias consumed 
roughly half the computer time provided by LARS. Consequently the 
wants and needs of users sponsored under Task 3A have received attention. 
Special support responsibilities have been assigned to the computer 
systems and the systems analysis groups within LARS Systems Services. 


In order for a promising new analysis technique to be shared, within 
the research community, recipients of the new technique must have; 

^Access to the software supporting the technique; 

^^Access to hardware which supports the software; 

^Access to the data required by the technique; 

*A technical understanding of the technique; and 

^Knowledge of how to operationally use the software implementation. 


To build a suitable environment for the Impler^ sntation, evaluation 
and exchange of remote sensing data processing techniques, Purdue has 
concentrated its efforts on providing access to suitable hardware, 
software utilities and data. Purdue has also provided consulting and 
training support to foster user knowledge of the hardware, software and 


*At Purdue, Ross Garmoe has supplied excellent basic systems support. 

Ross has been responsible for the design of the ^’TROUBLE" reporting system, 
the ”MAIL” facility and the re-design of the Batch system. He contributed 
extensively to theinstallation of the IBM 3031. 

Mon Li Tang and Peter Jobusch installed VSl and CSMP under VM on the LARS 
system. Peter also helped convert and install Release 8 of SPSS and the 
new CMS version of SAS . Mon Li made the systems changes necessary to 
install the 1200 baud capability for the statistical multiplexor and 
Trendwritter terminals at JSC. 
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data facilities which are available on the shared systeni. The means for 
transferring technical understanding of fruitful new techniques and their 
software implementations are the joint responsibilities the technique 
developer, the Intended recipient of the technique and the sponsor. We 
are in the process of investigating means of technique transfers which 
may be enhanced through use of the shared system. 


*Mary Ellen Pierson has been responsible for the JSC user disk backup 
system, generation of the User Group Accounting Reports, and handling 
the resource request system with Mike Collins. 

Luke Kraemer has been responsible for the design, creation, maintenance and 
upgrades of the P.T&E data base system. 

Sue Schwingendorf has managed the preparation of CMS short courses at 
JSC for February and December of 1979. She has also maintained the IMSL 
package, the SRTNEWS facilities, and Task 3A input to Scanlines. 

Bill Shelley has concentrated on viaiting consultant activities and on 
certain software support activities. Bill has been responsible for 
adding universal format capability to LARSYS Version 3. He has been 
responsible for the software products areas which support LARSPEC, 

LARSYS, SPSS and SAS. Bill has also managed the upgrade of NSECHO and 
GRP SAM. 

I thank Terry Phillips for his support, instruction, consultation and 
guidance. 

The efforts of Tom Wilson, John Dolan, Jeff Rogers, Mike Luttrell, Doug 
Forehand and Joe Whalen are also gratefully acknowledged. 

A very special thanks to Ruth Jarret, Katie Wolford, and Diana Dexter for 
their secretarial support. 
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2 . Hardware Components 

Several major computer hardware alterations occurred during the 
present contract year. These changes were necessary to satisfactorily 
support the expanded demand placed on the computational resources at 
LARS by the user communities at LARS and JSC. The most notable change 
was the replacement of the IBM 370/1A8 at LARS with an IBM 3031 m,achine. 
Disk space was also greatly increased to accommodate the expanding RTE 
data base at Purdue and the growing needs of the user community at JSC. 
Figures 1 and 2 present the LARS computer configurations as of 12/1/78 
and 12/1/79. 

There were also several communications hardware changes enhancing 
the accessibility of the shared data processing environment for JSC and 
ERIM. These changes will be discussed in System Access section of this 
report. 

2.1 370/148 Saturation 


Hardware is the backbone which computer facilities are built around. 
Any particular hardware configuration can support only so much computation. 

For the typical job mix experienced between 6/78 and 8/79, the IBM 
System 370, Model 148 at Purdue/LARS provided a satisfactory research 
computing environment when; 

*The hourly average CPU utilization was at or below 60% 

*The ratio of total working set size to available memory was below 
1.5:1. 

However, during this period, we experienced frequent saturacion of 
the day and evening shifts; 

*Afternoon working set to available memory ratios from 2:1 to 7:1. 

*As much as 40% of the available CPU cycles consumed in paging and 
overhead , 

*People waiting for the computer (extremely slow response times) . 


370/W8 CPU 
AND MAIN STORAGE 
(1 MEGABYTE) 



PURDUE/LARS COMPUTEPv CONFIGURATION AS OF 12/1/78 



















3031 Hardware Configuration 



PURDUE/LARS COMPUTER CONFIGURATION AS OF 12/1/79 
























LARS responded by attempting to more, evenly distribute the computer 
load through the day, by encouraging more efficient use of the computer, 
by investigating system bottlenecks and by investigating hardware 
alternatives. 

More. e.ven distribution of the computer load was encouraged through; 

^Training and verbal encouragement for use of the batch machines 
which ran during mid-nlghu to 8am (third shift) . 

*"Free'' third shift time for people to gain experience with and 
identify problems with third shift use. 

^Requests for user input concerning the utility of the batch 
machines and any specific, upgrade suggestions. 

^Investigation of measures of "overhead*’ charged to users during 
peak usage periods, 

*An adjvistment of rale.s encouraging midnight to Bam batch u.sago. 
More efficient computer usage had been promoted through; 

*AcqulvSitlon of the Fortran II Optlralxlng Computer 

’^•Publication and presentation of guidelines for efficient computer 
use and pi*ogramming . 

System bottlenecks were, examined through; 

*AcquislUiou of IBM's Virtual Machine Facility/37Q (VM370) 
Performance Monitor Analysis System (VMAP) . 

^Examination of computer queuing characteristics encountered under 
peak usage mixes. 

^Examination of paging and spooling characteristics of our system 
configuration. 

*Consult;it ion with IBM systems engineers. 

When these actions failed to Impact the day and evening shll t 
saturation problems, hardxrare alternatives were investigated and the 
decision x<rar reached to pursue acqviisitlon of a TPM 5031. 


2. 2 3031 Acquisition Plan 


The decision to acquire a 3031 v«»a reached in order to; 

*'Allow a larqor volume of highly interactive processing to bo 
done during the day and evening shifts. This would result in 
a more productive use of personnel who were constantly V\*aiting 
for the nuachine to respond to their interactive commands during 
the saturated day shift. 

'^Provide more computational power per dollar. Although the rental of 
a 3031 \wuld raise the cost of the LARS System Services by 10 percent 
the 3031 was expected to bo 2.25 times ns powerful as the 370/148. 
Since machine availability was the limiting factor, the additional 
computer power iivtas expected to be partially consumed, allowing 
a lov«rer effective rat®. 

s*iProvide a mox'e reliable operating env lro\uuoiU . The 3031 utilised 
somev^hat newer computer technology and was equipped with backup 
and debugging features not available on the 148. 

*Make pos.stblo the considerat ion of additional projects or expansion 
of current projects requiring computer resources. The saturated 
status of the 148 precluded any me;mingful expansion in total 
throughput on that machine. 

Pigure 3 presents a comparison of selected 3031 and 370/148 characteristics 
In general, not only v>as the 3031 more powerful than the 370/148, but 
It has character 1st It'S (onthoard channei logic, more channels, more 
memory, high speed buffering, etc.) which are more suited to the type 
of interactive, I/O and CPU intensive research wrk performed on our 
system* 


COMPARISON OF SELECTED CHARACTERISTICS 



IBM 370/148 

IBM 3031 

General; 



Instruction Set 

Equivalent 

Assist Packages 

Equivalent Except OS /DOS 

Machine Cycle Time 

180 - 270 ns 

116 ns 

Channels 

5 

6 

"Cycle Stealing" 

Yes 

No 

Dial-in-Servicing 

No 

Yes 

Storage: 



Size 

IM 

2M 

Maximum Size 

2M 

6M 

HIGH SPEED Buffer 

None 

32K 

4 -byte fetch 

N/A 

230 ns 

Fetch 8 bytes (Storage) 

810 ns 

805 ns 

Store 8 bytes 

1080 ns 

345 ns 


Figure 3 


Appendix A is the tasking document followed to achieve the successful 
Implementation of the 3031 at LARS. The anticipated Impacts of the 3031 
installation were expected to be: 

*A 2,0 to 2.5 increase in throughput capacity. 

*More efficient computer users after installation due to greatly 
improved response time. 

*No major applications software conversions. 

*Capacity for additional computer projects. 

^Minimal down-time during switchover. 

*A need to secure continued funding for the LARS computer at 
FY79 level. 

It was the funding issue which was the most sensitive at both Purdue 
and JSC. JSC could offer no positive guarantee tV\at funding would be 
available- to continue to support LARS at the PY79 level, but stated 
that the need for LARS computer service was there and that we were making 
a resonable request. After reviewing JSC's response in detail, and the 
benefits to be derived from the 3031, Purdue elected to acquire the new 
machine without a funding giiarantee from JSC. 
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2.3 Benchmark Testlns 


To insure that no major applications software alterations would be 
required, to obtain relative performance measures of the 3031 and 370/148 
and to allow rates to be established on certain LARS software products, 
benchmark tests were designed and conducted at LARS and on a 3031 at an 
IBM installation at Gaithersburg, Maryland . A number of important pieces 
of JSC software were included in this test. Personnel from NASA, IBM, 
and LEG helped construct and validate software for the benclimark test. 
Specifically the following were included; 


LARSYS 

IMSL 

SPSS 

EODLARSYS 
LARSYS P2 
LARSPEC 

Yield Modelling's Law of the Minimum 
CLASSY 


GLM ANOVA 

Landsat Reformatting 
Geometric Correction 
BATCH 
RSCS 

FORTRAN G 
FORTRAN H 
EDIT 


A representative of the JSC user community was present in Maryland to 
help support the testing on the 3031. The coimuunications link was also 
validated on the 3031 by transmitting and receiving data to and from 
thither sburg and the Data 100 at JSC. 

The results of the benchmark test indicated that a 2.9:1 improvement 
in throughput could be expected from a 3031 for the operating system and 
program mix normally experienced on the LARS facility. This result was 
surprising, being above the 2.25:1 which we had seen published. 

2.4 3031 Installation 


The 3031 was shipped on August 24 and arrived at Purdue August 29. 

By September 5 the 3031 components had been set in position in the LARS 
computer room, diagnostics run on the new components and certain minor 
hardware problems Identified and eliminated. The 148 teas disconnected 
at 6 pm on Thursday, September 6. Peripheral devices were uncabled from 
the 148, cabled to the 3031 and verified. The Benchmarks run at Gaithersburg 
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were then rerun at Purdue and the operators received hands-on instruction 
on the 3031. 

The 3031 was up and ready for general use Monday, September 10 at 
8 am, one day ahead of schedule. Benchmarks run on the machine installed 
at Purdue verified the roughly 3:1 improvement in performance. For 
further discussion of relative performance of the 148 and 3031, see 
Appendix B. 

2.5 Disk Storage Space 

During the second and third quarters, three IBM 3330 compatible disk 
units were installed. These units provided storage space needed by the 
SR&T data base, CSMP and the expanded needs of the JSC user community. 

In July the third 3330-compatible drive was installed to provide users 
of the 2314 drives a place to migrate as the. 2314's were phased out. 

The 2314 's have become obsolete and more expensive to maintain than 
newer, more reliable drives are to rent and maintain. The 2314 's will 
be removed completely from the Purdue facility during January of 1980. 

No additional disk space acquisitions are anticipated in the near future. 
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3 . Software Developmcn t 

During the past contract year the accomplishments in software 
development maintained a good balance between work on planned tasks 
and responsiveness to immediate user needs. In providing software 
services, this balance must be carefully maintained in order to avoid 
either being entirely reactionary with no overall plan to provide 
direction or having work planned in such detail that resources are not 
available to react to user needs. Figure 4 lists the software which has 
been implemented on the LARS computer. 

3.1 Systems Software 

An online problem reporting system was developed. Its purpose 
is to collect information about any problems encountered by users, at 
the time the user discovers a problem. To make a report, a user simple 
types ’TROUBLE* as a CMS command. The rest of the process is self- 
explanatory. 

A mail system was implemented to facilitate sending short message- 
type files to other system users, provide automatic notification that 
mail is being held for a user, and provide quick easy delivery of these 
files. Mail may also be sent to users who are not currently logged on. 
Mail is sent by typing *MIL userid fileid*, where userid is the ID of 
the person who is to receive the mail, and fileid is the filename and 
filemode of the file to be sent. A user wishing to know if mail has been 
sent to his ID, simply types ’MAIL*. If he has mail, it will be displayed 
on his terminal; if not, he will receive a message stating that he has 
received no new mail. 

Timelimit software was developed for interactive users. ’TIMELIMT’ 
is a command users may type during an interactive terminal session to 
set a CPU time limit for one or more succeeding jobs. The time limit 
is not job-specific, and will abend the user’s job when time expires. 
Parameters may be typed on the same line as the TIMELIMT command, or 
the program will prompt the user for information. Once set, the time 
limit may be queried, cancelled or changed at any time. 


SOFTOARE AVAILABLE ON THE LARS COMPUTER 
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EODLS development 




The SRTNEWS facility was updated to allow users to specify multiple 
output copies If the print parameter Is specified, and to reduce the 
number of pages required to print the set of current news Items. 

Nine subroutines were added to the FORTRAN H TXTLIB (FORTMOD2) . 

Eight of these, DEFINE, RENAME, REREAD, ERASE, DSDSET, LOGDSK, GETPAR, 
and TAPSET, were previously available for use with FORTRAN G. The other, 
DASDFI, is a new routine for Issuing flledefs for disk data sets from 
within a FORTRAN program. 

3.2 Statistical Software 


Purdue/LARS now has a statistical consultant to assist users In the 
use of SPSS and other available statistical routines. Development or 
conversion of special purpose statistical programs may also be requested. 
New releases of SPSS will be Installed as they become available. If a 
user encounters a problem of a statistical nature, he may contact 
Carol Jobusch at LARS. 

Due to delays In the schedule for SPSS to provide a working CMS 
version of release 8, LARS acquired the source code for release 8 and 
developed an overlay structure necessary for installation. 

Edition 7 of IMSL was installed on the LARS computer. As part of 
the revisions, 140 subroutines and entry points were renamed. 

SAS, the Statistical Analysis System, is now available on the LARS 
computer under CMS. It provides a wide range of statistical procedures, 
a variety of plot and chart routines, data management tools, ability 
to read complex files, and extensive report-writing capabilities. 
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3.3 Analysis Software 

Work was done on a data analysis procedure which is like Procedure 1 
in philosophy, but Incorporates local spatial information in both clustering 
and classification phases. The use of spatial information is achieved 
through use of an algorithm for Extraction and Classification of Homogeneous 
Objects (ECHO). An unsupervised form of this algorithm is used in 
clustering; a supervised version accomplishes the classification. The i 
compatibility of these two processors overcomes one of the observed 
shortcomings of the present Procedure 1 (viz., fundamental incompatibility 
of the Procedure 1 cluster and classification algorithms) . The proposed 
procedure is being implemented in five separate computer programs, in 
order to make maximum use of software already Implemented. 

Several enhancements to EODLARSYS were suggested. Among them were, 
the capability to use 800 bpi tapes, to have the data tape number appear 
on the output, and corrections to the LARSYS format output by DATA MERGE. 

Four new computer programs have been developed at LARS to allow 
communication between Purdue’s LARSYS and JSC’s EODLARSYS analysis 
systems. These programs convert a statistics deck or a results file 
produced by one system into a format which can be read and used by the 
other. To further insure compatibility, the LARSYS software has been 
modified to allow for Universally formatted data input. 

The LARS Spectral Analysis System (LARSPEC) was converted to run 
under CMS370. It was also modified to facilitate directly submitting 
LARSPEC batch jobs. Additional keys were also implemented for searching 
the spectral data base. 

Operation of the tape transfer software (TAPTRAN) has been running 
smoothly. To further the capability a procedure was developed for 
transmitting improperly terminated tapes. 


17 


l.*A Manage ment Soft ware 

Software was Implemented to provide additional accounting Information 
on the 3A contract beyond what is normally provided. This allows the 
Information to be broken down by user group. This report is produced 
weekly. Currently it is being modified to provide month-to-date entries 
and charges for software products. 

In response to disk hardware failures, software was developed to 
automatically back up 3A mini disks to tape. To minimize the risk of 
loss of work, this Is currently being done twice weekly. In addition, 
the entire LARS disk system is backed up once weekly. 

To reduce the amount of confusion in requesting resources, iroftware 
was developed to aid in this task. Now when resources are requested, 
such as a new ID or modifications to an existing’ one, records are 
automatically kept by the program as to when the request was made and 
when it was filled. Hardcopies of requests are sent to the operations 
group at LARS, the computer resources manager at JSC and the user when the 
request is entered into the system and when it is either filled or rejected. 

The initial implementation of this system occurred during the third 
quarter. Several problems have been encountered with the software design, 
especially in the request entry procedure. A more elegant design is being 
pursued and will be reviewed and implemented during the coming year. 
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3.5 BATCH Enhancements 


A new batch machine, BATHOUST, was added to allow users to run 
jobs requiring as much as 6 megabytes Os' 'semory. Jobs for this machine 
will be run at night with advance notice. 

To aid the user it, debugging br.tch jobs, a copy of the console 
output is generated an^. printed if an error is detected. 

Additional output routing capabilities were added. In addition to 
being able to route the output to any site, the output may now alternatively 
be routed to a userid. 

To aid the user in submitting batch jobs from a terminal, it is 
no longer necessary to use the NOHEADER option of the PUNCH command. 

As part of the overall conversion from CMS 360 to CMS 370, all but one 
of the batch machines now operate under CMS370. 

Currently, a re-design of the Batch System is being conducted. The 
goal of the redesign effort is to expand the users control over the batch 
system, reduce the amount of operator Intervention required to control 
the batch job stream and to more efficiently utilize the collection of 
virtual machines «;pporting the batch processor. 




3.6 Graphics Software 


A 3-dlmenslonal plotting tool that can be used In the development i 
of analysis routines Is now available. This new programming tool Is the 
3-D Graphics Compatibility System (GCS) obtained from the U.S. Army 
Corps Waterways Experiment Station. The USMA Graphics Compatability 
System is a FORTRAN based computer graphics system designed for use on 
a wide variety of computer graphics terminals. 3-D GCS is an upgraded 
version of 2-D GCS that has been available on the Purdue/LARS computer 
since May 1977. 

Work is continuing on utilizing the graphics capabilities of 
DECwrlter at LARS with the graphics board. Besides the typical plotting 
examples the DECwrlter has also been used to plot information from the 
USGS county DIME file. The potential benefits of utilizing the graphics 
capabilities to display user specified components of the RT&E data base 
are being explored. 
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4. System Access 

4.1 Communications Hardware Support. 

2780 Replacement. 

During the second quarter, the IBM 2780 at JSC was replaced by a 
second Data 100 with a tape transfer capability. The Data 100 functions 
as a HASP work station using HASP protocol. HASP protocol makes more 
efficient use of the communications lines between LARS and JSC, allowing 
more data transmission than 2780 protocol for any given baud rate. 

The 2780 at JSC had become somewhat unreliable due to its age. The 
Data 100 replacement has functioned well since its installation during 
the second quarter. 

2740 Replacement. 

During the first quarter, the two IBM 2741 Keyboard Terminals 
were replaced by Trendata terminals. The 2741 's worked at 13.8 characters 
per second and required one of the four clocks which could be attached 
to the 3705 to support that unusual rate. When installed, the Trendata 
terminals functioned at 30 characters per second, and were upgradable 
to 120 characters per second. The elimination of the 2741 's made it 
possible to replace the clock dedicated to them with a 1200 baud clock. 
This, in turn, made possible the installation of a statistical multiplexor 
and more efficient use of the band width dedicated to keyboard terminal 
communications . 

Dial-up Modem Installation. 

The Environmental Research Institute of Michigan (ERIM) had been 
accessing the LARS facility mainly to use LARSPEC and gain access to 
the field measurements data library. The utility of the system to 
ERIM was limited by the limited I/O available through a dial-up TI. 

ERIM utilized a COPE 1200 to access the >fTS system through a dial-up 
4“00 baud modem. The COPE was utilizing HASP protocol; however, it 
did not support a punch, only a reader and printer. The RSCS software 
at Purdue refused to communicate with the COPE when it received the 
"device not ready" message for the COPE's punch. This problem was 






resolved during the third quarter by revising the RSCS code. ERIM's 
COPE could then access LARS using their dial-up modem and the dial-up 
modem at LARS which is meant to accommodate the GODDARD installation. 

ERIM had to slgn-on as Goddard, and several minutes of system staff 
intervention was required to redefine the protocol associated with 
the GODDARD PORT <^Tom 2780 to HASP. 

During July, August and September, Purdue, ERIM, and the University 
of California at Berkeley (UCB) were investigating new ways of supplying 
JSC with research and development for the AgRISTARS project. At this 
time, it was agreed that use of the LARS computer for some development, 
all test, evaluation, and pilot work was the rational approach to 
the group’s computer resource needs. We, therefore, pushed ahead with 
the installation of a dial-up modem dedicated to ERIM. This greatly 
reduced the effort Involved in accessing LARS from ERIM. The expense 
of the long distance phone charges remains a concern of ERIM, however. 

It is hoped that the cooperation and sharing of software and data 
which could have accrued from the AgRISTARS vertical slice, may still be 
realized to some extent without it. After a trial period ERIM's mode of 
access to the LARS system should be re-evaluated for its cost-effectiveness. 

Statistical Multiplexor Installation. 

During the fourth quarter, the 7200 baud modem for the Houston 
line was replaced with a 9600 baud modem, increasing the data trans- 
mission rate between Purdue and JSC. Shortly afterwards, a statistical 
multiplexor was installed and the two Trendata terminals at JSC up- 
graded to 120 character per second operation. The statistical multi- 
plexor allows the device utilizing the modem to make maximal use of 
the available band -width upon demand, rather than dedicating a specific 
amount of band-width to each device. 
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Alternative Communication System Invest igat ion. 

One substantial cost of a remote terminal link is the charge for 

the coimnunications line (long distance or dedicated line cliarge) . We 

have been investigating the relative cost of the private network we 

now operate to those of telecommunication facility vendors, hoping 

to find a way to reduce leased line costs. The following vendors 

of telecommunications facilities have been contacted: 

Compute: Sciences Corporation (I'NFONET) 

General Telephone (WATS) 

Graphnet Systems, Inc. 

MCI Telecommunications Corporation 

Southern Pacific Communications Company 

Telenet Communications Corporation (owned by GTE) 

Tymnet, Incorporated (owied by Tymshare) 

Of these seven companies, only three have offerings of interest to us. 

GTE can offer us in-WATS service on either a metered time ($244 per 
month for the first 10 hours of uae and $18.31 per hour thereafter) oi' 

"full time" (1670 per month for the first 240 hours of use and $4.65 per 
hour thereafter) . In-WATS lines are. provided as pairs in rotary. Their 
use \rould serve principally as an alternate moans of funding long distance 
dial-up use for approximately the same coat as at present. (A one hour 
long distance call to Houston costs about $20) . Both asynchronous (tele- 
type type terminals) and synchronous (2780/3780/HASP) traffic could be 
accommodated . 

The other two alternatives are the Tymnet and Telenet packet switching 
networks. At present, neither can offer synchronous traffic support, 
although both companies intend to support it "in the. near future". With 
either company, the cost to LARS would be appi'oxlmately $1500 per month 
plus $1000 for Installation of equipment to interface our computer with 
the network. In addition to this, those who access the network would pay 
for connect time and data transmitted. These charges range from $5 to $15 
per connect hour and could be expected to total about $7500 per month for 
our present ti'affic. 


I 
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Until such time as our synchronous communications could be handled \ 

by one of these networks, no significant cost reductions to LARS and its 
user community are possible to offset the $9000 monthly cost of the packet 
switch network. At that time, we plan to re-evaluate their cost ^ 

effectiveness. 

i 

4.2 Usage Statistics 

Usage statistics for the Computer Processing Support Project 
indicate the success of the shared system concept. The computer 
resources consumed for the year are nearly double those consumed 
during FY78 (See Figure 5) . Figure 6 is a graph of the 370/148 
equivalent CPU hour usage for the Computer Processing Support Task 
from December, 1977 to November, 1979. Not only was a large increase 
experienced during FY79 but 690 148-equivalent CPU hours were consumed 
during the August through November time frame — that is a rate of 
2070 148-equivalent CPU hours per year (roughly 700 3031 CPU hours per 
year). Coupled with the increase in usage at LARS, the decision to 
acquire the 3031 appears to be justified. 

Figures 7 and 8 present the total CPU income usage on the 370/148 
and 3031, respectively. The height of the graph at the lowest bar 
is the computer usage of the Computer Processing Support Task; at 
the second bar, the usage funded through the SR&T contract with JSC; 
and at the top bar, all income usage. Computer hours consumed by the 
LARS Systems Services are not shoxm on these graphs. System Services 
CPU hours constitute approximately 30 percent of the total usage. 

These graphs clearly indicate the cost-effectiveness of sharing 
data processing facilities. The cost of a 370/148 based facility to 
LARS would have been 90 percent of the cost of a 3031 facility and 
would have been more than adequate for LARS computational needs. 

The 3031 facility increased computer power available to the JSC- j 

Purdue user community three-fold, while increasing costs only 10 percent. 









FIGURE 5 


COMPUTER RESOURCES CONSUMED 



Dec *77 

Nov *78 

Nov 

JSC Users 

26 

71 

96 

LARS Support 

3 

12 

19 

Deleted ID*s 


8 

3 

Batch Machines 


3 

4 

Library ID (JSC Disk) 


1 

1 

Total id's 

29 

95 

123 

370/148 CPU Hours, *year ending 

70 

694 

1374 


^Equivalent 370/148 CPU hours. 3031 CPU hours are multiplied by three to 
approximate 370/148 hours. 
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5. Data Base Management 


5.1 Receive Data Bases 


To support the research needs of the SR&T community over the past 
18 months, the following data bases were acquired for the LARS computing 
system: 

LACIE Phase I 

LACIE Phase III Blind Site Ground Truth 

Multicrop 

Corrected Phase III Ground Truth 

LACIE Transition Year Foreign Data Base 
These data bases were loaded onto tapes In Building 30 of Johnson 
Space Center (JSC) and shipped to Purdue. Upon reaching Purdue, the 
tapes were Inspected for data Integrity, correct blocking factor, 
file organization, and readability. Following completion of these 
tests. It was found that a sizable proportion of the tapes were unusable. 
Copies of these tapes were re-transmltted to LARS and re-tested. This 
Iterative process continued until a data base was complete and verified. 
The tape data base was then entered into the RT&E Segment Catalog 
and SUBSET data base. Users were notified of the installation through 
announcements in SRTNEWS and SCANLINES. 

Obtaining a set of usable data base tapes proved to be quite time 
consuming during the beginning of the contract year. Quality control 
checks of the tapes being generated in Building 30 were insufficient. 
Discussions with JSC and LEC personnel concerning these tapes has 
resulted in a marked improvement in the reliability of delivered tapes. 
Further improvements in quality assurance should be expected as 
verification techniques improve. 

5.2 Data Base Design & Implementation 

Much of the data base work this year involved building, maintaining, 
and verifying the Segment Catalog. As complete data bases are received 
at Purdue, information pertinent to each Acquisition is retrieved and 
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stored in the RT&E Data Base. This process is a continuing effort which 
requires monitoring. During the past year, a complete data reliability 
test was run on the Segment Catalog. This verification not only assured 
data integrity, but also provided a clieck on the usability of some of 
the older LACIE data tapes. 

An unexpected problem arose with the discovery that geographic 
locations associated with LACIE Segment Numbers are not always unique. 

Prior to that time, the Segment Catalog was organized with the Segment 
Number being the only master key. Since it was discovered that this 
arrangment could lead to geographic ambiguity, a new method of organization 
had to be devised. The latitude and longitude parameters were determined 
to be acceptable master keys to be included with the Site (Segment) 
number. This solution required a minimal expansion of the data base, 
minor software upgrades, and only a slight increase in data search 
time. 


The current RT&E Segment Catalog stored at LARS contains over 
43,000 Acquisitions. We expect to receive the LACIE Transition Year 
data for United States Sites soon. The receipt of this data set will 
expand the Data Base to over 55,000 Acquisitions. CMS file restrictions 
prevent any disk file from exceeding 65,536 records. Earlier this year, 
steps were taken to allow for the eventual growth of the Segment Catalog 
past the 65,536 record barrier. An additional Acquisition List File 
will be created to hold overflow data. The multiple acquisition files 
will form a single logical file. Links between the files will be 
maintained by two data items, referenced as the File Pointers, that 
have been added to all records in the Segment Index, Acquisition List, 
and Ground Observation Index. These pointers serve as flags to indicate 
which Acquisition File to read from next. 

Efforts to reduce possible wasted memory and CPU time resulted in 
the implementation of a linked list of available (or free) Acquisition 
File records. The next free record is always pointed to by the second 
data item in the Next Node File. 






During March, LARS obtained two IBM compatible, 3330 disk drives. 
Prior to this time, only portions of the Data Base were accessable to 
a user, due to a shortage of disk space. The 3330 drives provided 
freedom for growth and a significant decrease in data search time. 

Development of data bases at LARS resulted in a dialogue between 
JSC, LEG, and LARS concerning the Big-Dot Ground Inventory System. A 
preliminary meeting took place in July and a technical discussion group 
met In October. Technical memorandums were also delivered to LARS 
personnel during this interval. LARS has agreed to implement the 
Big-Dot Data Base and work will begin in December. 

5.3 Data Management Software 

Software development has proceeded along two paths: creating 

new software products and upgrading existing software capabilities. 

New software designed, tested, and implemented by the LARS 3A Support 
team Include programs to build the Ground Observation Index, a 
subroutine (GTINFO) to Query this ground truth data base, and a Segment 
Catalog Editor. This editor is a significant piece of software which 
aids in the maintenance of the data base. In order to maintain strict 
data control, the editor is only available to the Segment Catalog 
support personnel. 

Activities to expand existing software capabilities include the 
easing of restrictions on the usage of some software and conversion 
of querying subroutines to FORTRAN-H. In early versions of data 
support subroutines SEGFO, GETACQ, GTINFO, and SUBSET, certain guide- 
lines concerning disk access and logical unit definitions had to be 
adhered to. These restrictions have been lifted with minimal changes 
in the calling sequences. Conversion to FORTRAN-H had been hampered 
because of random access software problems which were not present in 
FORTRAN-G. The difficulties with the random access methods appeared 
to be related to the optimization performed at compilation. All routines 
have now been converted and work properly. All new changes and calling 
procedures will be formally announced during the LARS CMS Short Course 




to be presented at JSC in December. Information on changes to the 
data support subroutines is contained in Appendix D. 

5.4 Weather Data Base 


During the first quarter, NOAA personnel contacted LARS concerning 
the possible development of a weather data base on the LARS computer. 
Preliminary data and software requirements were discussed. A weather 
data base system (Appendix E) was designed and these recommendations 
were delivered to NOAA. This design was reviewed with NOAA during 
the July LARS consulting trip. A NOAA data requirement meeting was 
attended during this trip. Software delivery dates and task allocation 
were also discussed. Final functional requirements were received at 
LARS In September. Weather data covering daily observations, monthly 
summaries, and snow fall were ?.*equested for the months of March, 1979 
through June, 1979. This data was received in October. The data 
tapes were verified and entered Into the LARS tape library. 








6. Conu&unlcatlons, Consulting and Training 


This section deals with the personnel services portion of the 
Computer Processing Support Task. Training provides the background 
users require as a preamble to system use; consulting provides the 
expertise which helps to make users more efficient and effective; and 
communication is the glue which holds the "Support" portion of the 
task together. 

6.1 Visiting Consultant Trips. 

Problems encountered by remote users are frequently hard to fully 
understand or appreciate when described over the phone, especially when 
they require an understanding of the exact sequence of events, operating 
condition, etc. to diagnose. The immediate availability of an expert 
to answer questions and suggest approaches to software design and 
implementation is valuable. It is also extremely valuable to gain 
Insight into a remote users operating environment and resource needs. 

For these reasons LARS supplies visiting consultants to JSC for three 
days to a week once every two or three months as requested. Visiting 
Consultant trips also afford those responsible for certain design or 
development tasks the opportunity to discuss these tasks with Interested 
parties at JSC. 

Bill Shelley served as a visiting consultant at JSC from May 7 
to 11, 1979. He was able to provide general user consultation each 
day, present introductory lectures on the LARS computer system, meet 
with groups of people from NASA, LEC and IBM to consult on their use 
of the system, and discuss JSC testing contributions for the IBM 3031. 
Data base design recommendations were also discussed with NOAA 
representatives. 

From July 16-50, Luke Kraemer was at JSC to provide general 
consulting on problems encountered by LARS computer users, to discuss 
the possible implementation of a weather data base on the Purdue/LARS 
computer, to show the graphics capabilities of a DECwriter terminal, 
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to review the procedures for requesting computer resources and to 
encourage checking the quality of computer tapes before they are trans- 
mitted (via the computer for mall) to LARS. 

A two-day visit by Luke Kraemer and Peter Jobusch took place 
October 4-5. Besides providing general consultation for computer 
users, Luke and Peter attended discussions for future reference on 
how the data for LACIE was maintained and stored. 

The final consulting trip for the contract year occurred the 
week of November 12-16. Bill Shelley and Mike Collins were available 
to provide general user consultations, and to discuss how Purdue can 
provide more responsive computer resource allocations for JSC users in 
the coming year. 

6.2 General Consulting 

Consulting support is by no means limited to visiting consultant 
trips. A user seeking advice, help, system error correction, etc., 
may use the telephone to call someone at LARS or choose to use the 
interactive "MAIL" or "TROUBLE" features. In addition, some consulting 
support is available at JSC. For example. Bob Goode is responsible for 
supplying computer resources (Computer ID's, tape ring in assignments, 
disk space, etc.) to JSC users. Bob should be contacted with any 
questions about computer resource requests. Figure 9 lists Purdue 
personnel who may be contacted with consulting questions. 

6.3 Communications Study 

During the second quarter a study of the communications problems 
associated with contacting and receiving information and support, from 
systems services personnel was conducted. The objectives of this 
study were to identify what the overall responsiveness to user inquiries 
was, to identif’T which means of communication were important and effective, 
and which were not , and Identify what users view as the primary 
communication problems with System Service personnel. The questionnaire 
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FIGURE 9 
Consultant List 

ROSS GARMOE Systems Questions/Topics; the "MAIL", 

"TROUBLE", and "Batch" systems, RSCS problems 

MON LI TANG VSl and CSMP problems 

SUE SGHWINGENDORF SRTNEWS, IMSL, Scanlines Input, CMS questions, 

CMS Short Course 

LUKE KRAEMER Data Base Contents, Access, Support Software, 

General CMS consulting 

CAROL JOBUSCH SA3, SPSS, Statistical Consulting 

BILL SHELLEY EOD-LARSYS IPL System, Tape Transfers, 

LARSPEC, GCS, LARSYS, LARSYS support sub- 
routines (MOUNT, TAPOP, etc.) 

MARY ELLEN PIERSON Operations Procedures, CPU credit, System 

Backup 

JIM KAST Administration, software development, new 

projects, any subjects covered above or 
not listed 
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was distributed to three groups, the LARS Systems Service Personnel, 
System Service users at LARS, and System Services users obtaining 
computer service through the Computer Processing Support Task. 

Figure 10 presents the overall responsiveness of the LARS Systems 
Services personnel to user problems, as rated by these three groups. 

FIGURE 10 

OVERALL RESPONSIVENESS 



RESPONDENTS 

NASA 

SUPPORT 

CONTRACTORS 

VERY 

GOOD 

GOOD 

ADEQUATE 

NEEDS 

WORK 

TOTALLY 

INADEQUATE 

3A Users 

16 

10 

6 

7 

6 

2 

0 

1 

LARS Users 

15 



4 

7 

2 

2 

0 

System Services 
Staff 

16 




7 

4 

1 

1 

0 

TOTALS 

47 



15 

% 

20 

8 

3 

1 


It should be noted that roughly three fourths of the respondents 
evaluated the overall response to user needs/problems as Good or Very 
Good. Interestly, the overall rating given by the Houston users was 
even higher than that provided by users at Purdue. 


The value of communication and information transfer media were 
viewed somewhat differently by 'local users at Purdue and the users at 
JSC. JSC users rated the effectiveness and importance of common means 
of communication as: 

1. Personal Contact 

2. Phones ' ‘ 

3. Terminals 

4. Scanlines . 

5 . Memo 

6. Correspondence 

7. SRTNEWS, Documentation, Staff Meetings 

SRTNEWS was a new feature at the time the questionnaire was developed 
and was listed as a write-in. 
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Among the major problem areas, there was again good evidence of 
overall satisfaction on the part of JSC users. Using a 3, 2, 1, 0 
weighting for possible a list of communication problem areas, no problem 
area received a weighted average response as high as 1, Figure 11 
presents the responses to^the Problem Identification section of the 
questionnaire. 


FIGURE 11 

COMMUNICATION PROBLEM AREAS 




VERY 

SOME 

LITTLE 

NONE 

WEIGHTED 

AVG. 


WEIGHT 

3 

2 

1 

0 


1. 

« 

Inability to contact person 
due to absence from desk. 

2 

0 

7 

6 

.87 

2. 

Information given is not 
adequate. 

0 

4 

2 

8 

.71 

3. 

Promises for services are made; 
then not kept. 

1 

1 

4 

8 

.64 

4. 

Misinformation is given. 

1 

1 

2 

0 

.54 


Write-in problems included: 

- Don't know whom to contact should something go wrong. 

- Long delays in placing long-distance calls. 

- Too few people to interface with at JSC on a technical level. 

- Inadequate IBM and LARS documentation available. 

- System is slow and, sluggish. 

- Hard to get hold of part-time LARS Personnel. 

A JSC request to the FTS to place an FTS line to LARS would probably 
reduce the delays in long dtstancc. calls, particularly calls made after 
the Indianapolis FTS office closes. Considering the. volume of phone 
calls between Purdue and JSC, some real monetary savings might also 
result. 
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The Installation of the 3031 has probably eliminated the comment 
about the sluggishness of tlie system - which is not really a communication 
problem anyway. 

The level of expertise in use of the LARS computer has been rising 
at JSC. As it grows, the opportunities to interface with the elements 
of the JSC user community having a good technical knowledge of how to 
utilize the LARS facility, also Increases. 

In order to supply an input channel to users unable to contact the 
appropriate technical expert at LARS, the "TROUBLE" and "MAIL" interactive 
communication utilities have been developed. If a user wishes to report 
a problem he is having, he should simply type 'TROUBLE' on his terminal 
and follow the resulting Instructions. His request will receive a 
response whether or not he knows the rig'ut person to contact or if that 

person is present. The MAIL system allows a user to send a memo to i 

any ID, whether or not it is logged in at the time. 

6.4 CMS370 Training Courses 

During the week of February 5-9, 1979, a course on using the Purdue/ 

LARS computer was presented at JSC by Susan Schwingendorf , Luke Kraemer, 
and Bill Shelley. The main topic of the course was the use of CMS, but 
sessions were also presented on the availability of other software. 

Preparation is currently in progress for another CMS short course 
to be presented the week of December 10-14, 1979. Five instructors will 
be available at JSC during various portions of this week. They are 
Larry Biehl, Luke Kraemer, Peter Jobusch, Susan Schwingendorf, and 
Carol Jobusch. For this course, the topics have been divided into 19 
one hour modules, with prerequisites defined for each module. The 
first two modules are designed for newcomers to the Purdue/LARS computer 
and/or CMS. Six modules cover material on Intermediate level and deal 
with virtual machine concepts, CMS and Edit commands, beginning EXEC 
files, using BATCH and CMS commands for programmers. The remaining 
sessions cover more advanced aspects of the intermediate modules, or 






deal with the availability and use of other software. Tape/slide 
presentations of the course material for each module are planned and 
will be sent to JSC upon their completion. Appendix F contains the 
course outline and schedule for both the February and December CMS 
short courses. 


7. Administration 


The purpose of this section is to provide background information 
on the organization, philosophy and policies of the LARS Systems Services. 
This Information should help those utilizing LARS services better 
understand the environment from which the services flow. This Information 
may also present a model of how computer resource expenses may equitably 
by charged against those projects consuming the resources. Such 
Information may be of value to those planning the installation of a 
computational facility for remote sensing research within the Earth 
Observations Division. 

Much of the material contained in this section is contained in 
the "LARS Systems Services Administrative Plan for Fiscal Year 1980".^ 

The Administrative Plan is an internal document providing a detailed 
description of the LARS Systems Services; the philosophies, services, 
rate derivations, objectives, accounting system and approved rates. 

7.1 Systems Services Background 

Boundary Conditions. 

LARS System Services was established in February 1975 as a self- 
supporting enterprise of Purdue University. The objective of LARS 
System Services is to provide specialized and unique services to the 
Si/Onsored projects of the Laboratory for Applicqtions of Remote Sensing 
(LARS) at Purdue University within the following boundary conditions; 

*The enterprise will operate on a no-prof it/no-loss basis at a 

minimum financial risk to Purdue University.’ 

*The enterprise will provide services required by the LARS 
research community at acceptable levels of quality and quantity, 
and at cost effective rates. 


^ LARS Systems Services Administrative Plan for Fiscal Year 1980; 
T. L. Phillips, et. al., Internal Document of the Laboratory for 
Applications of Remote Sensing, Purdue University; July 1979. 


*The enterprise must attract a demand for services at a level 
equal to the minimum base required for effective rates. 

*The enterprise must provide a rate structure which offers 
uncomplicated alternatives from which the research community 
can plan resource needs. 

Cash Balances. 

Because LARS System Services is self-supporting, it must operate as 
near to a year-end balance of zero as possible. LARS has estimated that 
its ability to forecast the annual activity, thus income and expense 
budgets, is good to plus or minus 10 percent. However, applied to the 
operational level, we have found that the University is unwilling to 
let the cash balance drop to -10%. The philosophy of no negative cash 
balance then becomes an estimation error of 0 to +20%. That is to say, 
LARS System Services residual cash balance may be reasonable expected 
to fall between 0 and a positive 20% of that year's expenses. Any 
positive balance is carried into the next year and is counted as a 
contra-expense when new rates are calculated. 

Costing and the Rate Structure. 

LARS System Services is working under a costing concept. Part 
of condition 1 stated in section 7.1 is to offset expenses in any one 
year by income generated through a rate structure for the same year. 
However, because of the complexity of the income and expenditure budgets, 
it is likely at the end of any one' year to have income greater or less 
than expenses. The University has indicated an acceptability of a 
positive 20% carry forward. This carry forward must be distributed 
among the products that produced it in the successive year to lower 
the rates (or to avoid increasing them if services are being increased) . 
The distribution of this carry forward is made in July of the new 
fiscal year by the Deputy Director, based on data generated from the 
monthly reports. 




In calculating the rates for products, every attempt is made to 
Itemize all direct costs associated with each product. To properly 
Identify these costs and to develop data for their analysis, departmental 
reference numbers are used to assign expenditures to each product. The 
identified direct costs are divided by an estimate of unit demand to 
derive the unit rate. 

When trends touard excess income or expense are identified, attempts 
to reverse them will be made first by adjusting expenditures. Should 
this fall, rate adjustments may be required to regain balance. It 
should be noted that changes in the expenditure budget will normally 
be adequate because: 

a. If excess income is being generated it is likely that added 
demand should be met by adding resources. Note, however, 
when additional resources are not needed to meet additional 
demand, the rate should be lowered. 

b. If excess deficits are projected, it is likely that too much 
service is available, so expenses should be decreased. It 
may also be that not enough research personnel are demanding 
services. In this case. System Services personnel can be 
assigned to projects, thus increasing demand while decreasing 
costs. 

It should be noted that because of the relatively inelastic demand 
and the limited funding available at any given time for sponsored projects, 
rate adjustments may not generate enough additional revenue to avoid 
a deficit. 

LARS System Services does not attempt to recover "indirect" costs 
from users. Since all of the System Services users pay either indirect 
costs or administrative costs, it is inappropriate for LARS to make 
additional charges to the projects. 


Establishment of Products (Services) . 

A key to the success of the costing concept employed in Systems 
Services is the identification of meaningful, identifiable, products 
which will have a sufficient volume of consumption and whose production 
costs can be appropriately modeled through rates. New products are 
usually conceived by one of the System Services managers who maintain 
close contact with user needs and program capabilities. 

Before the product and its associated rate are established as 
part of the LARS product line, it is important to communicate the need, 
definition and estimated rate for the new product to personnel using 
or requiring the new product. For this reason, a procedure for establishing 
a new product has been developed. 

The procedure for establishing a new product includes maning the 
new product and Identifying it through a written description of the 
product including what it is, what can be expected from it, its avail- 
ability, and the measure of service which will be charged for the 
product. A rate for the new product must be selected by examining the 
production process for the product, its estimated income, and the 
expenditures required to produce the product. Each expenditure must 
be listed along with a description of why it is required as a part of 
the product. The income and expenditure budgets are then used to 
summarize the development of the rate. Finally, the effect of the 
product on LARS System Services objectives is documented. This 
information is then presented to the System Services managers and 
program leaders for their input. Assuming a favorable response, the 
new product will be approved by the Deputy Director, and a formal 
request for the establishment of a new rate will be prepared by the 
LARS Business Administrator. 

This year LARSPEC, LARSYS and Statistical Services were added as 
products under a new product category known as "Software Products". 

Previous to the creation of Software ?i*oducLs, maintenance of these 
software packages was charged to projects or underwritten by Computer 
and Priority Service through the rates charged for CPU time. Nov./ if a 
user docs not make use of one of these packages, he does not subsidize It. 


7.2 Evaluation of the Computer Processing Support Task. 


The Computer Processing Support Task has been beneficial to 
researchers at Purdue and JSC. This is evidenced by the near doubling 
of computer use at JSC; the reduction in the cost of computation for 
all users; the sharing of software and data by Purdue, NASA, IBM, LEC 
and to a much more limited extent ERIM personnel; and the creation and 
limited use of certain computer user communication facilities for 
LARS-JSC communication. 

JSC Benefits. 

The Computer Processing Task at LARS have served as a "pilot" for 
the concept of a shared SR&T computational environment. Such an 
environment could be supplied by a centralized computer system or 
through a network of computers. In one way or another JSC will: 

*Pay the bills for computer, personnel, and other expenses incurred 
by all the members of the JSC-sponsored research community. 

*Benefit from those fruitful new techniques which can successfully 
be integrated into Pilot and LSAT analysis system. 

A shared computational environment potentially provides: 

*User access, at all user locations, to the data, software, and 
documentation contained in the shared environment, 

*Sharlng of expensive portions of processing hardware at a cost 
advantage, 

*Sharing of software allowing flexibility in software maintenance, 
addition, and updating at a cost advantage over independent, 
non-compatible systems, and 

*Ease of training users and sharing and comparing new techniques 
through standard data formats, terminology, and shared 
communication channels. 
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The "pilot" shared data processing environment appears to be 
demonstrating many of these benefits. Users at JSC are making use of 
the field measurements data library and LARSPEC software at Purdue 
without : 

*havlng to copy, transport and verify a copy of the data base for 
JSC users; 

*convert the LARSPEC software to run on a different computer with 
a different operating system; 

*walt for the two Items abpve to transpire; 

*support the updating of the JSC LARSPEC or field measurements 
data base each time It Is updated at LARS; or 

^constantly running verification tests to Insure the two Implementations 
remain functionally equivalent. 

Similar statements could be made of LARS' use of LARSYSPl and LARS' and 
JSC's use of SAS, SPSS, IMSL, LARSYS, the RT&E data base, SCMP, GCS, etc. 

The acquisition of the 3031 Is a good example of the potential 
hardware cost savings. To supply the computational power needed by the 
SF3 research efforts of NASA, Purdue, LEG and IBM costs only 10 percent 
more than a hardware facility needed to supply the computational needs 
of Purdue alone (the 370/148) . 

Several communication channels have been developed which utilize 
the shared environment. Included are the SRTNEWS facility, the MAIL 
facility, the TROUBLE error reporting service, and the computer resource 
request system. The commonality of computer environments has allowed a 
CMS short course to be developed and presented to users at both JSC 
and LARS and for a hands-on version of the LARS Monthly Short Course to 
be presented at JSC at a cost savings over the expense of transporting 
15 NASA participants to Purdue. 

The computer systems in Buildings 12 and 30 at JSC were not 
specifically designed to support remote sensing research and techniques 
development. The machine at LARS, on the other hand, was. The Virtual 
Machine operating system (VM/CMS370) on the LARS computer has several 
very useful features. Each user is treated as if he were the sole user 


of a machine (hence virtual machine) . This concept allows the definition 
of machine memory size, devices available to the machine, etc. It allows 
very interactive processing modes without greatly sacrificing computer 
throughput, processing user Y*s job while waiting on input from inter- 
active input by user X. Certain earth resources data processing functions 
strain the ability of a machine to perform complex computations; others, 
the ability to handle large, complex data sets; others the ability of 
human interaction with intermediate results; still others combinations 
of these capabilities. The LARS computer allows a number of users to 
simultaneously use the real computer; each user specifying the machine 
configuration which will best suit the characteristics of his job. 

Not only can the aggregate of user-defined system resources surpass 
those actually available on the real machine, but any single user might 
define his virtual machine to have resources superior to those of the 
real machine. This operating system made possible the research and 
Implementation of geometric correction and registration processors on 
machine only a fraction of the size that would have been required had a 
more conventional operating system been employed. 

The reaction of the JSC research community to availability of 
this sytem is best reflected by the constant Increase In demand for 
computational resources by a user community of relatively stable size. 

(See Figure 6.) 

LARS Benefits 

While personnel and computer cost have been steadily rising over 
the last three years, funding for research work at Purdue has suffered 
a slight decline. Had JSC not been able to make significant use of the 
LARS computer, its continued existence would have been problematical. 
Without a computational facility much of the research work at Purdue 
would have been severely impacted . By using the LARS system to supply 
EOD computational support needs, Purdue's facility has been maintained. 

The remainder of this section is composed of excerpts of the 
"Financial Analysis of Fiscal Year 1979" Appendix C of the "LARS 
Administrative Plan for Fiscal Year 1980." This Appendix was written 
by Terry L. Phillips. 
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During 1979, the LARS System Services has achieved many significant 
objectives. Most of these are reflected in the Financial Statement, Some 
of them are highlighted here to provide the reader with the significance 
of the financial analysis. 

The first achievement of note is the sustained computer usage for 
the fiscal year. Eighteen hundred computer hours were projected for 
the year. Two thousand seven hundred thirty six hours were used. The 
hours were evenly distributed over the four quarters. This is the first 
year that we have had computer usage of over «ix hundred hours per 
quarter since 1973, and the first occasion of its happening since LARS 
System Services was started in February of 1975. 

There are at least two reasons for the increase in computer use 
during the year. One is the continued activity by remote sensing 
specialists at NASA in Houston, which provides increased usage and 
closer communication between LARS and the principal sponsor of LARS. 

The second reason is the use of batch services by computer users. Batch 
service has been encouraged by a batch training experiment in October 
and November of 1978, and by increasing the Priority Service rate. 

The resultant use has allowed the decrease of the rate for all computer 
services. 

The increased computer use led to the decision during the year to 
change computer systems. In September of 1979, the IBM 370/148 v;as retired 
in favor of an IBM 3031. The 3031 will increase the cost of computer 
services about 10%, and provide about three times the computer power. 

The usefulness of the computer to people is also reflected in the 
attached time, or the time in which people are using the computer. These 
figures show the amount of attached time since the IBM 360/67 went 
into operation in 1971, and include the attached time for this fiscal 
year. The attached time first went over the 14,000 hour level in the 
last quarter of last year. In every quarter of this year, the attached 
time was greater then 14,000 hours and was almost 18,000 hours during 
the first quarter of fiscal year .1980. 
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Another significant event of this year was the creation of Software 
Products. Although these products lost money this*y®a*^* their creation 

I 

has increased support of Important user software. It is expected that 
the Increased support will Increase usage and that the products will 
break even next year. 

During this year, a slgnif 'j.cant study was made on additional equip- 
ment required to Increase capability to Purdue researchers. The study 
resulted in a specific recommendation to purchase a color digital display 
and supporting equipment, and a recommendation to the Purdue Administration 
on a financial method of handling the purchase. These recommendations 
have been accepted, and it is expected that the equipment will be 
ordered next year. 

Anyone following the financial status of LARS System Services is 
aware that in the past, the status has been oscillating quite rapidly. 

It appears that the financial status is becoming more stable. It may 
be too early to predict stability, but the graph of bimonthly cash 
balance clearly shows that the period between the ups and downs is 
increasing, and does have some tendencies toward stability. 

These achievements, and others, are reflected in the financial 
analysis. The year-end f . ;rual financial reports for LARS System 
Services show that this past year is the first year we have had a 
positive balance since fiscal year 1976, and that the total activity 
is larger than any of the past years. It is significant that 
the amount of income obtained allowed greater expenditures in the 
personnel columns. These additional personnel approached levels that 
existed in fiscal year 1977, and have contributed greatly to our ability 
to provide quality services at a reasonable cost. 
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8. Recommendations 

8«1 EOD Computer System Development 

To meet the expanded computational needs placed on the NASA's 
Earth Observations Division (EOD) by the AgRISTARS project, EOD is 
pursuing the acquisition of a computer. This computer is not anticipated 
to be large enough to supply the computational of JSC's entire research 
community Including the universities and ERIM. The following recom- 
mendations are made for this syste. t: 

*It should be as compatible as possible with the system at Purdue/ 
LARS. Compatibility will ease the transfer of software from the 
LARS to the EOD machine, reduce the need for r.trainlng of JSC 
personnel, provide an environment of demonstrated value for 
research of remote sensing of agriculture and make possible the 
networking of the LARS and EOD machines. Additional consulting 
help would be available from LARS to aid EOD as it goes into 
the general purpose machine business. Also, the Purdue machine 
could be used for system development and test prior to the 
installation of the EOD machine. 

*It should be networked with the computer at LARS. In addition 
to maintaining the benefits of a shared computational environment 
which have been experienced by LARS and JSC for the past two years, 
networking makes possible access to software on either machine, 
overloan computing to be shared by both machines and backup 
computing in the event of failure of either machine. 

*Use of the network should be expanded to include all major research 
sites supporting EOD. In addition to reducing costs through reduced 
software development redundancy, reduced software conversion costs 
and reduction in the number of computer facilities EOD must support, 
it would also provide for a long term increase in productivi ty 
by reducing the time needed for technique transfers, making a fuller 
range of analysis capabilities available to all research sites, 
providing a mechanism for rosearch-community-wide communication, 
and e.l fin Inal Ing system df rfereiu’i's as delerants to understand Ing 
newly de.vc'lopi'd software l<‘e|m i(|ii{'s . 
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8.2 Establish a Research Community Baseline Systesa. I 

New technique developme and techniques exchange could be further j 

speeded if a modular, baseline research system framework were developed 
which would accomodate most new software techniques developed in the 
research community. Such a system structure would allow analysis system 
components developed at different sites to be easily compared or combined 
into hybird analysis systems without extensive re-programming. The 
development of such a system structure requires substantial thought, 
documentation, and communication, if it is to be successful. LARSYS 
Version III, LARSYSPl and QLINE are non-compatible examples of such a 
system concept. It is recommended that this system be implemented only 
after a joint NASA-Purdue-ERIM software design team has carefully 
examined alternatives. 

8.3 Programming Conventions Documentation and New Techniques Delivery Standards. 

In order to expedite technology transfer within the SR&T research 
community and between the research and the application communities, 
certain programming, documentation and software delivery standards 
should be established. One benefit of the modular baseline analysis 
system is that its framework will allow the addition or the replacement 
of analysis processors without requiring major system rewrites. There- 
fore, if all SR&T sites would deliver new techniques software in a 
form compatible with the modular system, virtually no additional pro- 
gramming would be, required to conduct tests comparing new techniques 
with each other and/or with the base-line system. In addition, making 
use of programming conventions, documentation and data delivery standards 
will greatly enhance the ability of researchers at the various sites 
to understand and utilize the software developed at other sites. JSC 

should allocate funds and assign members of the research community to ! 

a task force responsible for the creation of such standards. Standards 
would be beneficial, even if a shared computational environment were 

unavailable. s 
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8.4 Local Site Support Responsibilities. 

One key component to effective use of any data processing system 
Is the availability of an expert or consultant. These people are vital 
In the chain of communication between the people who maintain the system 
and the researchers attempting to make use of the system. In order to 
maximize the benefits which can be derived from the shared system, it 
will be convenient to establish a local site expert at each site. The 
site expert should be a technical specialist, familiar with computer 
programming as well as the technical aspects of typical remote sensing 
data processing software. At most sites It would probably be convenient 
for this person to double as a programmer. Site experts will need to 
spend two or more one-week periods a year becoming Intimately familiar 
with the processing network, new software utilities which have been 
added, reviewing problems, etc. with his peers at other sites. 

Each local site should also identify a person to serve as a 
computational resources manager. This person will be responsible for 
Interfacing with the network in order to secure and maintain the 
computational resources necessary to support users at his local site. 
Depending upon the amount of activity at the local site, the resources 
manager and the site expert may be the same person. 

8.5 Establish Training Course. 

A detailed training course for users of the network should be 
formulated; including: 

1. How to access and use the computer system. 

2. How to access and use the baseline software. 

3. How to use special SR&T utilities (batch, SR&T News, data 
search, etc.) . 

4. Programming conventions for research sof tware (e.g. , baseline 
system compatibility, universal format capability, commenting 
practices, transferability, etc.). 

5. Documentation standards. 

6. Standard algorithm evaluation and test procedures. 



7. Procedures for requesting data. 

8. Others. 


The CMS short course is a first step towards accomplishing number 1 and 
3 above. 


APPENDIX A 

WORKING DOCUMENT FOR 3031 INSTALLATION 



















Plan Impact Statement 



Figure A: Form Team and Do Initial Planning 
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A. Form Team and Do Initial Planning 
AO Secure Commitment from Key System Seirvices People 

Conduct meeting with Terry Phillips, Ross Garmoe, Keith Philipp, Jeanne Etheridge, 
and Mike Collins. Explain opportunity, secure commitment, 

Kast 1 man day 1/26/79 

A1 Allocate Task Responsibility 

Conduct team meeting and allocate responsibilities. Distribute Initial 
Planning Block Diagram and assign planning activities. Select next meeting 
time. 

Kast 2 man days 

A2 Plan JSC Case Kast & Phillips 
Kast 1 man days 

A3 Plan Impact Statement 

Plan the identification of impacts on SS projects (370 conversion, display, etc) 
Etheridge, Freeman, Garmoe. 

Etheridge 1 man days 2/6/79 

A4 Identify Hardware/Software Considerations Garmoe & Philipp 

Should identify the significant hardware changes necessary, and those important 
hardware/software components should be verified (2314 disks. Digital Display, 
CMS360, etc.). 

Garmoe 1 man days 2/11/79 

AS Plan Information Collection Philipp & Garmoe 
Plan tests and verification of problems turned up under A4. 


Philipp 

1 man days 

2/7/79 

A6 Plan Physical Arrangements 

Collins , Garmoe 


Collins 

1 man days 

1/31/79 

A7 Plan LARS Decision 



Kast and Phillips should define the information needed 
mode to be used in order for LARS to make the decision 
the 3031. 

and the presentation 
to attempt to acquire 

Kast 

,5 man days 

1/31/79 


AS Plan Software Conversion 

Garmoe & Philipp should identify those systems software which must be 
converted in order to support the 3031 and what tests should be conducted 
in order to confirm proper functioning of that software. 

Garmoe 1 man days 2/7/79 


2/6/79 

2/9/79 


“aac 
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A9 

Plan Operator Preparation 

Collins .5 man days 

1/31/79 

AlO 

Plan Operator Training 

Collins . .5 man days 

1/31/79 

All 

Plan Purdue Decision 



Assvuning a positive response by LARS towards the acquisition of 
activity is likely to be required of Phillips, Landgrebe and G. 
in order to secure Purdue approval. 

the 3031, 
Peterson 


Phillips 2 man days 

2/15/79 

A12 

Plan Test 



Philipp, Etheridge & Freemem 



Systems, Reformatting, applications such as LARSYS and LARSYSPl, statistical 
packages, accounting and other software should be benchmarked on an available 
3031 configured as closely as possible to match the projected LARS system. 


Philipp 2 man days 

2/7/79 

A13 

Plan User Education and Communication 



Etheridge .5 mem days 

1/31/79 

A14 

Plan Administrative Procedures 



Phillips 3 man days 

2/22/79 

A15 

Plan Evaluation 



Kast .5 man days 

1/31/79 

A16 

Plan Installation 



Garmoe & Kast 3 man days 

2/16/79 

A17 

Develop Test Preparation Plan 



Develop a plan for benchmark testing of the 3031 and acquiring 
and data needed to support the test. 

the software 


Kast & Shelley 6 man days 

4/10/79 

A18 

Plan CMS 370 Conversion Efforts 



Etheridge 6 man days 

4/10/79 


M 


Identify 



Figure B; Prepare & Present Case to JSC 












B. Prepare and Present Case to JSC 


Bl Identify Perceived Need 

Gather LARS internal emd JSC supplied evidence that the LARS system 370 
Model 148 computer is insufficient to handle the joint computational needs 
of LARS and JSC. 

Kast 2 man days 2/6/79 

B2 Develop Plan to Meet Need 

By reviewing the resources identified through the initial planning process, 
comparing those resources to the resources available within the computer 
facility and the computer processing support project over the period 
of the plan. This task requires the cooperation and input of System Service 
project managers. 

Kast. 2 man days 2/6/79 

B3 Assess Impact on JSC Projects 

Kast 1 man day 2/7/79 

B4 Assess Impact on JSC Productivity 

Kast 1 man day 2/7/79 

B5 Assess the Impact on JSC Cost 
Given the expected JSC usage based on Bl 

Kast 1 man day 2/8/79 

B6 Decide What Evidence is Needed from JSC 

Based on discussion in Directors' Meeting and with 3 A project manager, document 
the range of evidence needed from JSC. 

Kast 1 man day 2/9/79 

B7 Draft Case to be Presented for LARS Permission and later to JSC. 

Kast. 2 man days 2/14/79 

B8 Secure LARS permission' to talk with JSC about acquisition of 3031 
in Directors' meeting and Program Leaders Meeting. 

Phillips 1 man day 2/15,16,17/79 

B9 Raise JSC interest in 3031 acquisition and lay groundwork for 
presentation of LARS proposal for 3031 acquisition. 

Phillips .3 man days 


2/15/79 


B. Continued 


BlO Identify presentation and responsibility during Program Leaders 
Meeting or Directors' Meeting on 2/15-16/79. 

Phillips 1 num days 2/16/69 

Bll Make presentation to JSC to Jon Erickson, Don Hay and possible other 
JSC personnel. 

Phillips 3 man days 2/20/79 


Task B Total 


Kast 


16 man days 


2/20/79 


PLAN IMPACT STATEMENTS 
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C. Plan Impact: Statanenl; 

Cl Identify System Services Projects 
Obtain list of projects from managers. 

Etheridge man day 2/5/79 

C2 Identify Project Resource Requirements 

Ask managers to complete project lists by adding pers<xmel and precentages 
spent on prC'jects. 

Etherdige *s man day 2/5/79 

C3 Identify Preliminary Impacts 

Ask managers which projects may be impacted and which personnel and percentages 
are then available for 3031 project. 

Etheridge, Phillips 3 man days 2/28/79 

C4 Identify 3031 Conversion Resource Requirements 

Review plan and add up days needed for personnel for each month. 

Kast 2 man days 3/12/79 

C5 Review and Set priorities on System Service Projects in light of 
3031 Project. 

Phillips, all managers I man day 3/14/79 

C6 Assign 3031 Conversion Responsibilities 

Kast, all managers 1 man day 3/16/79 

C7 Make Impact Statement 

Based on all of above, summarize impact of 3031 conversion on System Services 
Projects. 

Etheridge 2 man days 3/19/79 


Task- C Total 


Etheridge 


10 man days 


3 / 15 / 79 . 
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D. Gather Hardware/Software Information 
Dl Examine 3031 Documentation. 

Garraop & Philipp 6 man days 2/7/79 

D2 Review the unique characteristics of the LARS system with 3031 
compatibility in mind. 



Garmoe 


2 man days 

2/7/79 

D3 

Based on Dl and 

D2 , produce a list 

of hardware/software 

concerns . 


Garmoe 


2 man days 

2/14/79 

D4 

Review concerns 

from D3 with IBM. 




Garmoe 


1 man day 

2/21/79 


D5 Flag concerns for negotiation between Purdue Purchasing and IBM 
(see Boxes M16 and M17) . 


Kast 


2 man days 


2/22/79 
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E. Make LARS Decision 

I El Review Evidence Resulting from Work on Impact Statement, Hardware/ 

J Software Considerations, and the Verbal and Expected Written Responses 

^ from JSC during a 3031 conversion team meeting. 

Review the risk and opportunities in light of this evidence. 

Phillips 2 man days 2/21/79 

E2 Identify 3031 Hardware Requirements. 

Quantities and model number of each component of the 3031 we plan to 
order and each component of the 148 we plan to discontinue should be 
documented for inclusion in our letter of intent to Purdue University. 
(Box E5) 

Garmoe 1 man day 2/22/79 

I 

i 

! E3 Prepare Case for Purdue by Documenting the evidence and the 

I criteria vinder which LARS is seeking to acquire the 3031. 

\ Kast, Phillips 1 meui day 2/22/79 

E4 Secure Conversion Team Commitment 

i On the basis of the information presented in Box El, secure personnel 

commitment to the pursuit of the 3031 by each member of the conversion 
team. 

, Kast 1 man day 2/21/79 

E5 Prepare Letter of Intent for Purdue University. 

Combine iiformation in Boxes E2 and E3 in a suitable form and present 
to Dave Landgrebe. 

Kast 1 man day 2/23/79 

E6 Seciure LARS Approval during Program Leaders Meeting 2/23/79 by 
reviewing Boxes El and E4 for Program Leaders Meeting. 

The entire conversion team should be present at this meeting. 

Kast 1 man day 2/23/79 

E7 Communicate Decision to Purdue 

Landgrebe 2 man days 2/27/79 

' '• V.,; 

E8 Establish conversion account. 

I Phillips 1 man day 3/19/79 
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OPERATORS PROCEDURE PREPARATION 1 


i 


FL. Study the IBM manuals on the 3031 system. 

Collins 4 man days 5/1 

F2. Review existing computer operator's guide to determine areas 
that will need to be changed or rewritten. 

Collins 3 man days 6/30 

F3. Prepare rough draft of Computer Operator's Guide. 

Collins 4 man days 7/3 

F4. Review draft with Basic Systems Group. 

Collins 2 man days 8/7 

F5. Identify any questionable areas that will need to be tested 
during the Washington tests (if needed) . 

Collins 1 man day 5/30 




figuration of 
LARS 3031 






G. SOFTWARE CONVERSION 


G1 . Install LARS modifications into VM370 Rel 5, PLC 12. Test modified 
system, and install as production system on LARS 370/148. 

Philipp 10 roan days 4/11 

G2. Negotiate test site configuration. 

Garmoe 1 man day 4/9 

G3. Define set of tests for CP, CMS and RSCS and the required operational 
levels and test results. 

Garmoe 3 man days 4/20 

G4. Define libraries and test materials required to perform testing at 
test site. 

Philipp I man day 4/20 

G5. Validate operation of CP, CMS and RSCS on LARS 370/148 using tests 
and test materials defined above, using system generated in Gl. 

Philipp 2 man days 4/16 

G6. Freeze production system and configuration, except for mandatory 
changes. 

Garmoe 1 man day 5/1 

G7. Generate LARS system for test on 3031. Involves modifications to 
DMKRIO, DMKSYS, DMKCPI and DMKCKP and generating IPL tape. Also 
generation of 3705 EP program and test system directory. 

Philipp 6 man days 5/7 

G8. Prepare test materials for transfer to test 3031 in apfropriate 

manner. May be 3330 packs and/or tapes. 

Garmoe 4 man days 5/7 

G9. Determine the channel configuration of the LARS 3031. 

Garmoe 1 man day 4/1 
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1. Pre-Installatlon 3031 Test 

11. Confirm the test date requested for Gaithersburg under Box R with 

Hast 1 man day A/19 

12. Reserve the 1A8 for Saturday evenings, and arrange for operators 
for those evenings. 

Kast 1 man day A/ 20 

13. Prepare for and run CPU Strain Test using LARSYS, CLUSTER and 
LARSYSPl Classify. Involves Kast, Shelley, Lang and operator. 

Shelley 6 man days A/21 

lA. Run Standard Mix Test using LARSYSPl, EDIT .string LARSYS, SPSS and 
the FORTRAN H compiler; optimize 1 and 2. 

Shelley 6 man days A/28 

I 

15. Run Standard Mix Test, using the processing in Box lA, Intensive 
CPU and intensive paging background loads on the system. 

Kast • 7 man days 5/5 

16. Run the Paging Strain Test, using a progression of Geometric Correction 
jobs running simultaneously. 

Shelley 6 man days 5/12 

17. Run JSC Software Benclnmarks on Procedure M (if available), LARSYS-P2 , CLASSY, 
TAPTRAN, LAW of the Minimum and Generalized Analysis of Variance Software. 

Shelley 6 man days 5/9 

18. Run LARS Software Benchmark (for rate establishment) on EXOSYS, Referts, 

IMSL and CP accounting. 

Etheridge 6 man days 5/26 

19. Bring up 3031 at test site with test directory. 

Garmoe 3 man days 

Philipp 3 man days 6/1 

110. Test on 3031. Same tests as Boxes 13-18. 

Shelley 2A nian days 6/5 

111. Teat oper.Ttor procedures and gain operator experience. 

Collins 5 man days 6/5 

112. Analyse test results. 

Garmoe, Kast & Shelley 5 man days 6/7 


: . . . . 
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113. Publish in SCANLINES. This will be done continuously to keep users 
informed. 

Shelley 4 man days 6/20 

114. Archive test results. Information may prove helpful during next 
machine conversion. 

Shelley 2 man days 6/20 

115. Report and Evaluation. Where were the bottlenecks and problem areas? 
How could it have been done better? 

Shelley 4 man days 7/1 
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J> Physical Planning 

Jl. Chart present physical layout of computer room. 

Collins 2 man days A/ 1/79 

J2. Secure templates of the 3031 and CDC 38302 controller for use 
in planning layout. 

Collins 1 man day 4/6/79 

J3. Meet with IBM site preparation man to secure power requirements, 
divide work on layout planning (J4), etc. 

Collins 1 man day A/6/79 

JA. Work with IBM to plan intermediate, 2-miachlne and final 3031 • 
configurations. Secure approval of Project Manager (Hast) atid 
Facility Manager (Phillips) . 

Collins & IBM 5 man days 5/30/79 

J5. Check flooring requirements in all three configuration plans (JA), 
and order new pieces if necessary. Cut flooring to accommodate 
power cables. 

Collins 1 mar. day 6/3/79 

J6. Write order to. electric suppliers for power receptacles as specified 

by IBM (J3), and an order to physical plant for installation in positions 
specified in layout plan. Order connector cables from IBM. 

Collins 3 man days 5/1/79 

J7. Insure physical plant installs required power for 3031, console, 

IBM disk controller and CDC disk controller. 

Collins 1 man day 7/1/79 

J8. Move 1A8 to Interim position, clearing space for incoming 3031 hardware. 
IBM 7/15/79 

J9. Work with IBM to ensure an appropriate hardware system maintenance plan 
is developed by Field Engineering. 

■ Garmoe 3 man days 7/1/79 

JIO. Order CDC 38302 disk controller. 

Garmoe 1 man day • A/15/79 

Jll. Determine IBM FE requirements for 1A8 move and 3031 installation. 

IBM ' 5/22/79 


( 
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K. Operator Retraining 

Kl. Finalize the draft of the Computer Operators Guide that was 
begun in F. 

Collins 10 man days 8/15/79 

K2. Develop and finalize plan for retraining and educating computer 
. operators. 

Collins 5 man days 9/1/79 

K3. Present the retraining course to the computer operators, together 
with operators' documentation. 

Collins 10 man days 9/13/79 
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Figure L: USER EDUCATION & COMMUNICATION 
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L. User Education & Communication 


Plan Seminar I 

Plan to present general information to users: why and how we will get 
the computer, testing plans, etc. 

Kast 1 man day 4/10/79 

L2. Present Seminar I 
Planned under LI. 

Kast h man day 4/20/79 


L3. Document 3031 Progress in SCANLINES 

Keep users informed of 3031 progress, beginning in March, ending ir. 

November . 

Etheridge 2 man days March - June 

Shelley 2 man days July - October 


L4. Complete Computer User’s Guide 

Revise for the 3031 and have copies available for distribution at 
Seminar II. 

Garmoe 5 man days 9/25/79 


L5. Consult with programmers on CMS370 Conversion 
Help programmers with 370 conversion problems. 

Etheridge 3 man days 

Garmoe 1 man day 


8/20/79 


L6 . Plan Seminar II 

Review 3031 installation, down time, results, user Impact and 
outline future plans. 

Kast 2 man days 10/9/79 

L7 . Present Seminar II 

% man day 








Kast 


10/1/79 


Meet with IBM, Achieve final 
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M. Administrative Procedures 

Ml. Meeting of Product Managers for instruction on Administrative Plan. 
Phillips 

Product Managers 2 man days 4/15/79 

M2. Initial documentation of Chapters I through III of Administrative Plan. 


Phillips 5 man days 


5/1/79 

M3. Expenditure budget guidelines. 

Phillips 2 man days 


5/15/79 

M4. Expenditure budget with description of all items. 
Product Managers 18 man days 


6/1/79 

M5. Estimation of product usage. 

Product Managers 6 man days 


6/15/79 

M6. Financial analysis for FY79. 

Product Managers 12 man days 


7/15/79 

M7. Rate request 

Phillips 2 man days 


8/1/79 

M8. Initial System Service project plans. 

Phillips 3 man days 


6/1/79 

M9. Second Systems Service project plan 

Project Managers 10 man days 


7/1/79 

MIO. Final System Service project plan. , 

Phillips 2 man days 


8/1/79 

Ml 2. Lease/Pucchase analysis 

G. Peterson 2 man days 


9/1/79 

Mil. System Services accounting system description. 
Collins 5 man days 


8/1/79 

M14. Approval of System Services administrative plan. 
Phillips 2 man days 


9/15/79 


Product Managers 


M13. Documentation and decisions rega'rding .1980 budget. 

Phillips 3 man days 8/15/79 
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M15. Contact Purdue and National Computer Equipment Corporation on the 
sale of the 148 for the rental credits accrued over our two-year 
rental period. 

Phillips 3 man days 6/1/79 

M16. Meeting of Systems Group, IBM and Purdue Purchasing to discuss our 
needs to Insure an operational system upon Installation of the 3031. 

The 4507 digital display and the 2314 disk system were of primary 
concern. 

Kast 4 man days 4/3/79 

Ml 7. Negotiate a final agreement with IBM on a procedure to validate the 
3031 upon Installation. 

Purdue Purchasing 7 man days 6/1/79 

M18. Finalize planning for 3031 acquisition. 

Kast 2 man days 5/15/79 















Strain test 













N. 3031 Installation 


Nl. Conduct a pre-installation review meeting between LARS and IBM 
representatives to finalize installation plans and establish a definite 
installation schedule. 


Kast 3 man days 8/15/79 

N2. Ship the CDC 38302 disk controller and cables from the factory. 

CDC 7/15/79 

N3. Receive the CDC 38302 disk controller and cables from the factory. 
CDC 8/1/79 

NA. Ship the IBM 3031 and its associated hardware from the factory. 

IBM 8/2A/79 


N5. Conduct pre-installation review with remote terminal resource managers. 
Schwingendorf 2 man days 8/30/79 

N6. Inform LARS users of schedules for shutdowns, tests and operational 
startup of the new 3031 system. 

Kast 1 man day . 8/25/79 

N7. Receive the 3031 snd its associated hardware from the factory. 

IBM 9/3/79 

N8. Unpack the new equipment and set up the 3031 and its new components 
offline. Run preliminary tests. 

IBM 9/5/79 

N9. Install 38302 and CDC disk system on the 370/148. 

CDC ' 8/7/79 


NlO. Inform IBM of production shutdown on 370/148. 

Garmoe H man day 

Nil. Attach all peripherals to the 3031 and check them out. 
IBM 


9/6/79 

9/7/79 


N12. Bring up VM and test it with the IVP (Installation Verification 
Program) . 


Ga rmoe 


1 man day 


9/9/79 


N13. Test 3705 Emulator Program System and test 3705 loading and 
operating features. 

Garmoe 1 man day 9/9/79 

N14. Test RSCS with JSC. 

Garmoe 1 man day 9/9/79 

N15. Run acceptance test and test code for 3286 hardcopy of console log. 
Garmoe and others 1 man day 9/9/79 

N16. Rerun systems software tests; also run accounting and directory 
tests. 

Garmoe 

Collins 2 man days 9/9/79 

N17. Rerun CPU Strain Test. 

Shelley and others 1 man day 9/10/79 

N18. Rerun Standard Mix Tests. 

Shelley 

JSC 1 man day 9/10/79 

N19. Rerun Paging Strain Test. 

Shelley 1 man day 9/10/79 

N20. Rerun rate establishment tests. 

Shelley and others 1 man day 9/10/79 

N21. Provide operators with hands-on experience in the power-up, power-down 
and operation of the 3031. 

Collins. 10 man days 9/10/79 

N22. Obtain practical experience in controlling and operating the 3031 
for computer operators. 

Collins 4 man days 9/10/79 

N23. Inform IBM so that they can remove 370/148 equipment. 

Garmoe 1 man day 9/10/79 

N24. Upon removal of the 148, complete the physical layout of the computer 
room. 


Collins 


4 man days 


10/1/79 








■■ 
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0. Production & Evaluation 

01 Bring up and establish 'Mive” user directory needed to support all users 
of the LARS system 

M. Collins 1 man days 9/10/79 

02 Begin regular production with 3031. 

R. Garmoe 2 man days 9/11/79 

04 

Continue to resolve any "problems" and "loose ends". 

R. Garmoe 10 man days 10/15/79 

03 Conduct post-installation review meeting and review task leader 
evaluation reports. (Kast, Phillips, Garmoe, Collins) 

J, Kast 6 man days 10/15/79 

05 Evaluate the installation process and report. 

T. Phillips 3 man days 10/31/79 

Task O Total 

Kast 22 man days October 31 



5/23 5/2: 



Figure P: CMS370 Software Conversion for 3031 Test 



P. CMS370 Application Software Conversion 


PI. Install 3330 disk drives. This roust be done in order to have all 
needed disk space available for converting to CMS370. 

Garrooe 10 roan days 

Collins 3 roan days 

Philipp 2 roan days 3/23 

P2. Assign disk space for all application systeros. hake list of needs 
and update directory. 

Etheridge 1 man day 

Collins 1 roan day 3/30 


P3. Announce CMS370 support. Write up item for SCANLINES. 


Garrooe 


1 man day 


3/30 


P4. Complete G-compiler txtlib. Some special CMS routines are needed, 
mainly for computer facility users, in the G-compiler FORTRAN 
txtlib on the CMS370 disk. 

Philipp 5 man days 

Wilson 5 man days 3/30 

P5. Convert essential standard LARSYS routines. TAPOP is the only 
outstanding one. A couple of last changes have to be made, and 
documentation completed. 

Shelley 3 man days A/ 10 

P6. Convert CP accounting. The programs are being tested now. Thj 
BACKUP routine has to wait for completion of standard LARSYS 
(See Box 18). 

Garmoe 3 man days 

Etheridge 1 man day 

Pauley 6 man days 5/23 

P7. Convert Batch controller. We have 370 batch machines but ID BATCH, 
the controller, still runs on CMS360. The programs are converted 
but not tested (Steve Pauley converted them). Tested in Box 18. 

Etheridge A man days 

Kraemer 10 man days 

Pauley 6 man days 5/23 

P8. Convert standard LARSYS. PHOTO, TAPUTL and a handful of minor 

routines need to be converted. The 18 standard processors are up 
and running. 

Etheridge 
Shelley 
Schwingendorf 


A man days 

2 man days 

A man days A/30 




P9. Convert REFERTS to be tested in Box 18, 

Kozlowskl 3 man days 5/23 

PIO. Convert the Geometric Correction Processor in preparation for 

testing under Box 16. 

Kozlowskl 4 man days 5/11 

Pll. Convert EXOSYS. Steps that have been done; divorce EXOSYS from 

the Reform disk, get rid of need for old EXOSYS and just have 

EXOSYSDV (as EXOSYS). GCS txtlibs for CMS370 will be put on the 
EXOSYS disk until another decision is made after 3031 Installation. 
Tested in Box 18. 


Etheridge 

Heinrich 


4 man days 
6 man days 


5/23 


Set up IPL I Convert 

systems K LARSYSDV 



for 3031 Installation 
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Q. CMS370 Conversion for 3031 Installation 


Ql. Set up CP hooks for IPLing LARSYSDV and Reform under CMS370. 



Garmoe 

2 man days 

5/1 

Q2. 

Convert LARSYSDV to CMS370. 




Shelley 

4 man days 



Etheridge 

3 man days 

7/30 


Lang 

6 man days 

1 Q3. 

Convert Reform IPL system to 

CMS370. 



Kozlowski 

6 man days 

6/15 


Q4. Reorganize CMS370 systems disk, and establish specialized systems 
disks for PLTLIB and SPSSLIB as read-only extensions. 

Etheridge 2 man days 

Philipp 3 man days 

Wilson 2 man days 5/15 

Q5. Complete the conversion of LAIS and be?;ln operational use under 

CMS370. 

Graham 20 man days 5/1 

Q6. Complete conversion of reformatting, accounting, tapehandler, 
registration system, color product processing system, etc. 


Kozlowski 

15 man days 


Smith 

10 man days 


Murphy 

3 man days 

8/30 

Complete conversion of 

the Fiscal Accounting System, 


Etheridge 

5 man days 

4/30 

1 


i 

I 


L 



Prepare for Software Testing 
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R. Prepare for Software Testing 


Rl. Formulate the goals of the testing process. Candidates Include 

software validation, benchmarks for establishment of rates, bench- 
marks for JSC to make decisions on distribution of thelc computing 
tasks, acquiring JSC ownership. 

Shelley & Kast 1 man day 4/10 

R2. Meet with IBM. Review preparation, procedures and options for 3031 
test. 

Kast 3 man days 4/3 

R3, Contact users of the LARS system, allowing them to nominate software 
for Inclusion in testing. 

Shelley 2 man days 3/18 

R4. Identify software to be tested, based on standard products and user 
input . 

Shelley 3 man days 4/10 

R5. Determine tesr configuration and communicate request to IBM. The test 
configuration should mirror, to the greatest extent possible, the ant- 
icipated configuration to be installed at LARS, and should be able to 
fully support the software to be tested. 

Gannoe & Shelley 3 man days 4/10 

R6, Design tests to evaluate how the 3031 performs under a progression 
of standard LARS job mix; under extreme CPU and paging conditions; 
and how standard software performs under the 3031, relative to its 
performance on the 148. 

Shelley & Kast 5 man days 4/12 

R7. Meet with IBM; review test goals, tests, time requirements and con- 
figuration. 

Kast 2 man days 4/13 

R8. Segregate software into conversion categories (convert for test, 

convert for installation, not to be converted before installation, etc.) 

Shelley & Etheridge 4 man days 4/12 
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APPENDIX B 


RELATIVE CAPACITIES OP THE LARS 370/148 and 
3031 COMPUTER CONFIGURATIONS ~ PRELIMINARY FINDINGS 
by Peter Jobusch 

For capacity measurement purposes, we regard a computer system as a 
three dlmlnslonal object. The three axes are CPU power, main storage 
capacity, and I/O subsystem capacity. We have expanded In two of the 
three dimensions with the Installation of the 3031 system. Specifically, 
the CPU power has about tripled and the main storage available to 
users has expanded from 160 to 416 pages (a factor of 2.6). The 
capacity of the I/O subsystem, while unchanged. Is now more available 
for user I/O because paging has been virtually eliminated. 

The 3031 system Is clearly performing much better than the previous 
370/148 configuration. It Is performing so well, in fact, that we have 
experienced a drop in the number of active users as people get their 
work done and can log off the system (see Figure 1) . It remains to be 
seen how much more work the 3031 can perform. Extrapolation from current 
levels of use to estimate the maximum number of users the system could 
support is risky for two reasons. First, the present level of use is low 
relative to system capacity. Second, the relationship between the number 
of active users and the service levels provided are non-linear due to 
queuing effects. This non-linear effect can be seen most clearly in 
Figure 2 which shows a dramatic reduction in service levels provided by 
the 370/148 system as the active user load increased beyond ten. 

Utilization of the three dimensions of the computer system is shown in 
Figures 3, 4, and 5. Judging from these graphs, and their implied 
functional relationships, we estimate that the 3031 system can adequately 
support between 20 and. 25 active users and still provide an overall level 
of service (as measured by the resource availability index) of about .8. 

This conclusion is drawn from data gathered during the first two 
weeks of 3031 use. As more data are analyzed and more experience 
gained with the system, it will be refined. 
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U4/1B/79 Q9/0<»/79 FIGURE 2 

BASE VAOIASlE - ACTIVE 
SVH CROSS'VAR SCALE ORG 


- resource AVAILAHILIIV INDEX (RA1> 
VERSUS NUMUEH Oi- ACTIVE USERS 

» USERS ACTIVE IN A SAMPLE INTERVAL 

AVG hax oesch:ption 


• RAI 

* RAI 

BASE 

value 


0.10 

0.10 


0,h7 

oiss 


1.00 VALUES FROM 3031 
1.00 VALUES FROM IMB 


TOTAL 



1ST X-VAR 
1 WUBS CUM9 

0 .i.... ... 

I 60 0 

t 10S9 22 

2126 67 

1170 60 

279 66 

5H 66 
2b2 67 
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bO 99 
31 loo 
0 100 
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0552 
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AObS CUM« 





10 loo 
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09/1B/79 09/04/79 FIGURE 3 - PLOT OF VIRTUAL MACHINE CPU UTILIZATION 

VERSUS NUHdEK OF ACTIVE USERS 

BASE variable - ACTIVE « USERS ACTIVE IN A SAMPLE INTERVAL 

SYM CROSS-VAR SCALE ORG AVG MAX DESCRIPTION 

VIRTCPU*’" Io"oO "’iolTO ""vvTIb VALUEs”fROm"303T'”’ 

» VIRTCPU 10.00 66.55 97.26 VALUES FROM l6B 


BASE 

VALUE 


6 

5 

6 

7 

8 
9 


13 


total 



1ST X-VA9 2M0 X-VAR 
1 »UBS CUM« (#OtiS CUM« 

• 0 ..• 6 .- ... 


I 

I 

I 




I 

7 6 9 ^ 


bO 

0 

0 

0 

18S9 

22 

0 

0 

2126 

47 

0 

0 

1170 

60 

90 

2 

279 

64 

30 

3 

SB 

64 

29 

4 

2S2 

67 

116 

11 

491 

73 

149 

169 

75 

29? 

19 

334 

79 


22 

748 

86 

359 

32 

SH6 

95 

209 

38 

329 

98 

m 

41 

oO 

99 


31 

100 

B99 

87 

0 

100 

6l9 

99 

0 

BS52 

100 

30 

3594 

100 


Of *VV' - ^ 
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OV/18/79 09/04/79 FIOURE 4 - TOT*L SrSTEM PACING PER SECOND 

VEWSUS NUMHtk OF active USERS 

dASE variable - ACTIVE • USERS ACTIVE IN A SAMPLE INTERVAL 

SYM CROSS'VAR SCALE ORG AVG MAA DESCRIPTION 

PAGERATe”” ToIoO VALUE s"rM0M’303l 

* PACERATE 10.00 31. 8S 71. US VALUES F'RUM l4b 


dASE 

value 
0 

\l 

4 • 

5 

6 
7 

1 ? 

II 

16 

total 


! • 

# 

I • 
' • 




# 


1ST X-VAP 2mD X-VAR 
• ObS CUMf f$o^S CUM* 


1^0 


0 

0 

18S9 

2126 


0 

0 

0 

0 

U70 

60 

90 

2 

279 

64 

30 

3 

bH 

64 

29 

4 

2S2 

67 

116 

7 

491 

73 

149 

11 

169 

7S 

297 


i34 

79 

93 

22 

748 

88 

3S9 

32 

5H6 

9b 

209 

38 

329 

98 

Ps? 


60 

99 

62 

31 

100 

899 

87 

0 

100 

419 

99 

0 

100 

3U 

100 

• • 


tt552 3S9A 


09/18a^79 09/04/79 FIGURE 5 - PLOT OF VIRTUAL MACHINE I/O RATE 

VERSUS NU'^btH OF ACTIVt USERS 

BASE variable - ACTIVE N USERS ACTIVE IN A SAMPLE INTERVAL 

SYM CROSS-VAR SCALE ORG AVG MAX DESCRIPTION^ 

"" Vi'r*"*"** loIoO ***** **2elh0 330J#39 VALUES FROM 3UJ1 
♦ VIO 10,00 24,41 32/. 47 VALUES FROM 148 


BASE^ 

value 


4 

s 

6 

7 

8 
9 


11 

12 

\t 


total 



1 

0 


I 


I 

I 

0 


1ST X-VAR 2mD X-VAR 
i^OBS CUM+ 40riS CUM* 


60 

0 

0 

0 

1859 

22 

0 

0 

2126 

47 

0 

0 

1170 

60 

90 

2 

279 

64 

30 

3 

58 

64 

29 

4 

252 

67 

116 

7 

491 

73 

149 

11 

169 

75 

297 

19 

334 

79 


22 

74H 

88 

359 

32 

btt6 

95 

209 

3b 

329 

9H 

122 


60 

99 

?b2 

62 

31 

100 

899 

87 

0 

100 

419 

99 

0 

100 

30 

100 


8b52 3S94 
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Format of Next Node File 


Entry 



Format 

Bytes 

Number 

of 

Segment Index Records 

.1*6 

1-6 

Next Available Acquisition List Record 

1*6 

7-12 

Number 

of 

Dot Label Records 

1*6 

13-18 

Number 

of 

Crop Names 

1*6 

19-24 

Number 

of 

Crop Status Records 

1*6 

25-30 

Number 

of 

Ground Observation Records 

1*6 

31-36 

Number 

of 

Observations Field Records 

1*6 

37-42 

Number 

of 

Repeated Measurements Records 

1*6 

43-48 

Number 

Unused 

of 

Acquisitions 

1*6 

49-54 

56-80 


Note: This file contains only one record. The Next Available 
Acquisition List Record pointer is actually the head of a linked 
list of available Acquisition Records. These free nodes are connected 
through the Next Acquisition data item found in the Acquisition List. 
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/ 


Format of Segment Index Records 


/ 

Entry 

Format 

Bytes 

Date Segment Initiated (YYDDD) 

1*4 

1-4 

Segment Descriptor (county, state, other) 

8A4 

5-36 

Acquisition List Pointer: First Entry 

1*4 

37-40 

Last Entry 

1*4 

41-44 

Label Index Pointer: First Entry 

1*4 

45-48 

Last Entry 

1*4 

49-52 

Ground Observation Index: First Entry 

1*4 

53-56 

Last Entry 

1*4 

57-60 

Segment Number 

1*2 

61-62 

Segment Center Latitude (minutes north) 

1*2 

63-64 

Segment Longitude (minutes east) 

1*2 

65-66 

Country (number coded) 

1*2 

67-68 

State (number coded) 

1*2 

69-70 

County (number coded) 

1*2 

71-72 

Agro-Physical Unit 

1*2 

73-74 

Crop Reporting District 

1*2 

75-76 

File Pointer for First Acquisition 

L*1 

77 

File Pointer for Last Acquisition 

L*1 

78 

Unused 


79-80 


Format of Acquisition List Records 


Entry 

Format 

Bytes 

Sensor System 

AS 

1-8 

Previous Acquisition 

1*4 

9-12 

Next Acquisition 

1*4 

13-16 

Orbit Number 

1*4 

17-20 

Scene Frame ID (SFI) 

1*4 

21-24 

Reference SFI 

1*4 

25-28 

Reference SFI for Ground Observations 

1*4 

29-32 

Date Data Collected (YYDDD) 

1*4 

33-36 

Time Data Collected (GMT) 

1*4 

37-40 

Date Entered In (YYDDD) 

1*4 

41-44 

Goddard Processing Date 

1*4 

45-48 

Date of Unload Tape 

1*4 

49-52 

Peak Sharpness 

R*4 

53-56 

Normalized Peak to Background Ratio 

R*4 

57-60 

Segment Number 

1*2 

61-62 

Sun Elevation (min.) 

1*2 

63-64 

Sun Azimuth (min.) 

1*2 

65-66 

Tape Number 

1*2 

67-68 

Lines of Data 

1*2 

69-70 

Columns of Data 

1*2 

71-72 

PFC Bias for Channel 1 

1*2 

73-74 

PFC Bias for Channel 2 

1*2 

75-76 

PFC Bias for Channel 3 

1*2 

77-78 

PFC Bias for Channel 4 

1*2 

79-80 

PFC Gain for Channel 1 

1*2 

81-82 

PFC Gain for Channel 2 

1*2 

83-84 

PFC Gain for Channel 3 

1*2 

85-86 

PFC Gain for Channel 4 

1*2 

87-88 

Cloud Cover 

L*1 

89 

Processing Flag 

L*1 

90 

Greeness of Soil Line 

L*1 

91 

XSTAR Haze Parameter 

L*1 

92 
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Format of Acquisition List 

Records 

j 

Entry 

Format 

Bytes 

File Number 

L*1 

' 93 

First Channel 

L*1 

94 j 

Last Channel (NC) 

L*1 

95 

Crop Year Designator 

L*1 

96 

Landsat Number 

L*1 

97 

Data Classification 

L*1 

98 

i 

File Pointer for Previous Acquisition 

L*1 

99 

File pointer for Next Acquisition 

L*1 

100 

Unused 


101-120 



Format of Dot Label Table Records 


Entry 

Previous Label Entry 
Next Label Entry 
Segment Number 
Analyst Identifier 
Number of Categories 
Labelling Convention 
Experiment 

Date of Labelling (YYDDD) 
Acquisitions Used in Labelling 
Date //I (YYDDD) 

Date #2 (YYDDD) 

9 

Date m (YYDDD) 

Category Names 

Crop Annotated as Category 1 
Crop Annotated as Category 2 
Blank fill or Crop Annotated 

m- 

Blank fill or Crop Annotated 
Pointer to First Test Field 
Pointer to Last Test Field 
Pointer to First DO/DU Field 
Pointer to Last DO/DU Field 
CAM/ CAS Tape Number 
CAM/CAS File Number 
Number of Labels (NC) 

Labels and Annotation 

Labelled Line for Dot 1 
Labelled Column for Dot 1 
*Dot Label for Dot 1 
**Dot Annotation for Dot 1 



Format 

Bytes 


1*4 

1-4 


1*4 

5-8 


1*2 

9-10 


L*1 

11 


L*1 

12 


1*2 

13-14 


1*2 

15-16 


1*4 

17-20 


1*4 

21-24 


1*4 

25-28 


1*4 

39-52 


1*2 

53-54 


1*2 

55-56 

Category 3 

1*2 

57-58 

Category 30 

1*2 

111-112 


1*4 

113-116 


1*4 

117-120 


1*4 

121-124 


1*4 

125-128 


1*2 

129-130 


1*4 

131-132 


1*2 

133-134 


1*2 

135-136 


1*2 

137-138 


1*2 

139-140 


L*1 

141 


Format of Dot Label Table Records 


Entry 


Format. Bytes 


Dot Status for Dot 1 

• 

L*1 

142 

• 

• 

• 

Labelled Line for Dot NO 

1*2 

127+8*NC-128+8*NC 

Labelled Column for Dot NC 

1*2 

129+8*NC-130f8*NC 

*Dot Label for Dot NC 

1*2 

131+8*NC-132+8*NC 

**Dot Annotation for Dot NC 

L*1 

133+8 *NC 

Dot Status for Dot NC 

L*1 

134+8*NC 


1 _ N - 30 Type one dot corresponding to category name N 
** 129 - N - 158 »“Type two dot corresponding to category name N-128 


** 0 == A Field Pixel 

1 =*“ Dot in DO Area 

2 == Dot in DU Area 

3 == Dot is an edge pixel 

4 =* Dot is a boundard pixel 


Crop Name. List 


Entry 

Format 

Ml 

Name for Label 1 

A8 

1-8 

Variety for Label 1 

AS 

9-16 

Name for Label 2 

A8 

17-2A 

Variety for Label 2 

• 

• 

• 

A8 

25-32 

• 

« 

• 


Crop Status List 


Entry 

Name of Status 1 
Name of Status 2 


Format Byte 
A8 1-8 

A8 9-16 


Ground Observations Table 
Ground Observations Index 


Entry 

Format 

Bytes 

Previous Ground Truth Entry 

1*4 

1-4 

Next Ground Truth Entry 

1*4 

5-8 

Segment Number 

1*2 

9-10 

Number of Fields Monitored for Agronomic Data 

1*2 

11-12 

Date of Initial GT Record (YYDDD) 

1*4 

13-16 

Date of GT Reference (YYDDD) 

1*4 

17-20 

Pointer to Acquisition List for first W to W GT 

1*4 

21-24 

Pointer to Acquisition List for last W to W GT 

1*4 

25-28 

Pointer to first Monitored Field 

1*4 

29-32 

Pointer to last Monitored Field 

1*4 

33-36 

Crop Year Designator 

L*1 

37 

File Pointer for first Acquisition 

L*1 

38 

File Pointer for last Acquisition 

L*1 

39 

Unused 


40-50 


Observation Field Records 


Entry 

Format 

Bytes 

Previous Field ^fonitored 

1*4 

1-4 

Next Field Monitored 

1*4 

5-8 

Segment Number 

1*2 

9-10 

Field Number 

1*2 

11-12 

Field Identifier 

A8 

13-20 

Crop Names Entry 

1*2 

21-22 

Crop Status Entry 

1*2 

23-24 

Date Planted (YYDDD) 

1*2 

25-26 

Nitrogen Fertilization 

1*2 

27-28 

Row Width (meters) 

R*4 

29-32 

Pointer to first of Repeated Measures Data 

1*4 

33-36 

Pointer to last of Repeated Measures Data 

1*4 

37-40 

Number of ARCS (NARC) 

1*2 

41-42 

Line Coordinate 1 

1*2 

43-44 

Column Coordinate 1 

1*2 

45-46 

Line Coordinate 2 

1*2 

47-48 

Column Coordinate 2 

1*2 

49-50 


Line Coordinate NARC 
Column Coordinate NARC 


1*2 

1*2 


3 9+NARC*4 -4 0+NARC*4 
4 1+NARC*4 -42 -NARC*4 


Repeated Measurment Record 


Entry 

Format 

Bytes 

Previous Measurement 

1*4 

1-4 

Next Measurement 

1*4 

5-8 

Segment Number 

1*2 

9-10 

Field Number 

1*2 

11-12 

Date Measured (YYDDD) 

1*4 

13-16 

Maturity 

L*1 

17 

% of Ground Cover 

1*1 

18 

% of Green Leaves 

L^»l 

19 

Condition 

L*1 

20 
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CHANGES TO RT&E DATA BASE SOFTWARE 


APPENDIX D 

CHANGES TO RT&E DATA BASE SOFTWARE 


A new version of the RT&E data base was made available Monday, 

August 27th. For two weeks following that date, both the old and new 
versions were available. Afterward, the old version was removed. 

The new version of the data base and Its accompanying software 
can be accessed In the same way as the old. The software Is located 
on JSCDISK 19A, which must be accesssed as a B-dlsk. There have been 
a few changes, however. The software for the new version can be 
accessed by loading the text files *SEGF02', ’GTINF02', 'GETACQ2* 
and/or 'RTEERR*, depending on the subroutlne(s) desired. When using 
the new versions of SEGFO and GTINFO, you need no longer make any 
special FILEDEFS. 

SUBROUTINES SEGFO AND GTINFO 

CALL SEGFO (SEGNUM, ACQCNT, ACQ. INDEX, ERROR, DEVICE) 

CALL GTINFO (SEGNUM, ACQCNT, ACQ, INDEX, ERROR, DEVICE) 

Both of these subroutines now have an additional Input argument. It 
Is ’DEVICE,' and INTEGER*4 variable used to pass to the subroutine 
a data set reference number that the subroutine will use to access 
the files of the data base (this parameter takes the place of the 
previously-needed FILEDEFS.) When writing programs that use these 
subroutines, you should pass each subroutine a unique DEVICE number 
that Is used for no other purpose. Also, the routines no longer 
vnrlte out error messages: they simply return an appropriate value 

In the ’ERROR' parameter. An Informative message can still be obtained 
by calling the new subroutine ’RTEERR’, which Is described further below. 
SUBROUTINE GETACQ 

GALL GETACQ (UNIT, SEGNUM, ACQ, ERROR, DEVICE) 

GETACQ, like SEGFO and GTINFO, also requires that the final parameter 
In the call be DEVICE. This variable serves the same function as 
the one used In SEGFO; therefore, follow the same rules stated above. 
GETACQ also no longer prints out error messages, but the messages 
can be displayed by calling RTEERR. 


NEW SUBROUTINE RTEERR 


CALL RTEERR (E, DEVICE) 

Usage Notes: If an error message is desired, call RTEERR immediately 

after the call to the routine in which the error may have taken 
place (either SEGFO, GTINFO, or GETACQ) . You must pass as argument 
*E' the varlaole which contains the return code from the routine 
in question, and as 'DEVICE' you must pass the data set reference 
number of the device on which you wish the error message to appear. 
Please note: the 'DEVICE' must be previously defined with a FILEDEF 

command . 

FORTRAN-H versions of the RT&E Data Base Software will be formally 
Introduced to the JSC users during the LARS CMS Short Course in December 
The software for these versions can be accessed by loading the text 
files 'SEGFOHX', 'GTINFOHX', 'GETACQHX', and/or 'RTEERRHX'. These 
texts are stored on the JSCDISK 19A. The new software though, unlike 
the FORTRAN-G versions, does not require that this disk be accessed 
as a B-disk. A new argument 'MODE*, an INTEGER*2 variable, must now 
be passed to SEGFO, GTINFO, and GETACQ. t®DE must follow the parameter 
DEVICE in the three calls, and in all cases, indicates how the JSCDISK 
19A was accessed. I'or example, if the follov^lng command was Issued 
in CMS370: 

GETDISK JSCDISK 19A C 

MODE must then be set to the character string *C1'. The first 
character always signals the RT&E software how the disk was accessed 
and the second character must always be a one. 

A FORTRAN-H version of SUBSET, the data base Inquery software, 
will also be announced in December. Major modifications have been 
included in this new version will be discussed thoroughly during the 
Short Course. 










APPENDIX E 

DESIGN CONSIDERATION FOR NOAA WEATHER DATA BASE 


NOAA Weather Data Base System 
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NOAA Weather Data Base File Structure 
Regional Dally Data File for Past 546 Days 


Record 

Data Item 




Format 

Bytes 

1 

Maximum Temperature 




5461*2 

1-1092 

2 

Minimum Temperature 




5461*2 

1-1092 

3 

Maximum Temperature Flag 




546L*1 

1-546 

3 

Minimum Temperature Flag 




546L*1 

547-1092 

4 

Free ip it ion 




5461*2 

1-1092 

5 

Free ip it ion Flag 




546L*1 

1-546 

5 

Free ip it ion Trace Flag 




546L*1 

547-1092 

6 

Present/Past Weather Flag (Synoptic Time 

1) 

546L*1 

1-546 

6 

tf tt tl ft 

If 

It 

2 

546L*1 

547-1092 

7 

It tf ft tt 

tl 

It 

3 

546L*1 

1-546 

7 


It 

It 

4 

546L*1 

547-1092 

8 

tt tt ft It 

tl 

tt 

5 

546L*1 

1-546 

8 

It tf tt tt 

It 

tt 

6 

546L*1 

547-1092 

9 

It tt ft It 

ft 

II 

7 

546L*1 

1-546 

9 


tt 


8 

546L*1 

547-1092 

10 

Number Reports During Day 




546L*1 

1-546 

10 

Number Reports Indicating Precipitation 


546L*1 

547-1092 


(Note: This layout is for the first reporting station of each Regional 

Daily Data Pile, The second reporting station of each file wuld reside 
in records 11 through 20. The number of records each of these files 
contains depends on the number of sites in that region; therefore, a 
region x^ith 23 stations xTOuld require 230 records of size 1092 bytes. 


NOAA Weather Data Base Building Procedure 


When the weather data base is initially loaded on to the system, 
none of the data items will have any values. To fill the data base 
with information, NOAA must first decide what is the earliest date 
they wish to refer to. This date will then be defined as the base 
date. NOAA will then furnish LARS the weather data from the base 
date to the present. The R.egional Dally Data Files will then be 
loaded with this weather data. The first value of each data item 
for all these files will contain data from the base date. The 
second data items will hold all data from the day after the base 
date. This loading process continues until the 546th day. Data from 
this day is loaded into the 546th or final position for all data 
items in the Regional Daily Data Files. The data base ds then full; 
however, what is to be done with future data? The data base as 
designed in this outline calls for the writing-over of the oldest 
data with the most recently received data. For example, if LARS 
received 14 days worth of data from NOAA after the data base had 
been fully loaded, data from the base date and the following 13 days 
TOuld be replaced by the new data. The base date would be incremented 
14 days and the base date position would be 15. That is, the oldest 
data in the system will then be found in position 15 of all data 
items and the most recent data would be in position 14. This circular 
loading process continues as more data is received at LARS. 


NOAA Weather Data Base File Structure 


System File 


Data Item 

Format 

Bytes 

Region File Size 

1*2 

1-2 

Site File Size 

1*2 

3-4 

Base Date 

1*4 

5-8 

Base Date Position 

1*2 

9-10 

Number of attributes 

L*1 

11 

Unused 


12-20 


(Note; This file contains only one record) 


NOAA Weather Data Base File Structure 


Region File 

Data Item Format Bytes 

Region Name 24A*1 1-24 

Region Number 1*4 25-28 

Regional Daily Data File Name 8A*1 29-36 

Regional Daily Data File Size 1*2 37-38 

Pointer to First Reporting 

Station in Site File 1*2 39-40 

Unused 41-50 

Site File 

Data Item Format Bytes 

WMO 5 -dig it Station Identifier 1*4 1-4 

4 Character Airways Callsign 1*4 5-8 

Latitude of Station 1*4 9-12 

Longtitude of Station 1*4 13-16 

Station Elevation 1*4 17-20 

Reporting Station Short Name 10A*1 21-30 

Pointer to Region File 1*2 31-32 

Pointer to Regional Daily Data File 1*2 33-34 

Unused 35-50 
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PURDUE/ZARS SHORT COURSE OUTLINE 
Presented at Johnson Space Center 
February 5 - February 9 $ 1979 

MONDAY 



9:00 am 


10:30 


1:30 


9:00 aia 


10:30 


I. Introduction (Susan Schwingendorf) 

A. Course Instructors 

B. Consulting Team at LARS 

C. Consulting Team at JSC ^ 

II. Overview of LARS Computer System (Bill Shelley) 

A. Hardware (capacities) 

B. Operating System 

C. Accessing the Computer 

IDs, passwords and Beginning CP Comm£utds 

(Logon, Logoff, Ipl, Query, Begin, SPool, REMOTE, DETach, 

PURge, DISC, IND, MSG) 

III. CMS370 Editor (Luke Kraemer) 

LUNCH 

IV. Beginning CMS370 Commamds (Susan Schwingendorf) 

(Listfile, Type, PRint, PUnch, READcard, GETDISK, Query, 

COPYfile, Rename, ERASE, RELease, TAPMOUNT, TAPE) 

V. ''Hands-on" for Editor and CMS370 Commands 

- At least one instructor will go to LARS terminal area 

- Other instructors may go to other areas of the building 
at the request of course participants. 

TUESDAY 

"Hands-On" (continued) 

VI. CMS370 Commands (Part II) (Susan Schwingendorf) 

(Query, SET, Listfile, STATE, COMpare, COPYfile, SORT, TAPE, 

BACKUP, MOVEfile, DISK, SYNONYM) 

VII. Algorithm Implementation (Writing & Testing Progreuns) (Bill Shelley) 

A. Efficient Progreunming Practices 

B. Commands to Create, Modify and Move Data Files 6 Programs (Review) 

C. Compiling Your Program 

D. Commemds to Develop and Test Progreuns 

E. Debug Commands 

LUNCH 


1:30 VIII. Beginning EXEC File Creation (Luke Kraemer) 

TV. '’HAnd«;-On'' for CMS370. Runninc. Proqrams and EXECS 



128 


WEDNESDAY 


"Hands-On” (cont) 

9:30 2 UH ' X. Batch Machines (Luke Kraemer) 

A. Names & Timelimits 

B. Batch Header Cards 

C. Including EXEC routines - (read & write passwords) 

10:30 XI. EXECS (Session II) (Bill Shelley) 

LUNCH 

1:30 XII. CMS360 to CMS370 Conversion (Susan Schwingendorf) 

XIII. "Hands-On" for Batch, EXECS & Conversion 

TH URSDAY 


"Hands-On" (cont) 

9:00 am XIV. Additional Software Capabilities on the Purdue/LARS Computer 

A. Timelimit-allows user to disconnect job overnight 

without fear of using 12 hrs. of CPU time 

B. Data Base Referencing Functions 

SEGFO, GETAQ, SUBSET 

c. Tape Manipulation - Copying, Dumping, Testing Tapes 

D. LARSYS Runtable Search 
B. Preprocessing Software 

F. Data Analysis Software- LARSYS, LARSYSPl 

Availability & Documentation 

G. IMSL 

H. Statistical Packages - Availability & Documentation 

I. Other utility subroutines available from LARSYS 
(e.g. to get date, time, user name, etc.) 

J. EXOSYS - brief description and availability of documentation 

LUNCH 

Complete "H2mds-0n" 

Work out individual problems in using the Purdue/LARS computer with instructors 

FRIDAY 

Instructors will be available until mid-aftemoon to assist users with their 
system use problems. 
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Purdue /liARS CMS Short Course Schedule 
December « 1979 


Level 


MONDAY 

8:30 

Introduction to VM370 

(Introductory) 

December 10 

9:00 

HANDS-On 



10:00 

CMS X 

(Introductory) 


11:00 

HANDS-ON 



1:30 

Virtual Machine Concepts 

(Intermediate)' 


2:30 

CMS II 

II 


3:30 

HANDS-ON 



TUESDAY 

8:30 

EDIT I 

(Intermediate) 

December 11 

9: 30 

EXEC I 

If 


10; 30 

HANDS-ON 



1; 30 

Programming I 

(Intermediate) 


2 : 30 

Batch I 

II 


3:30 

HANDS-ON 



WEDNESDAY 

8:30 

Programming II 

(Experienced) 

December 12 

9:30 

Stat Packages 

(Intermediate) 


10; 30 

RT&E Data Bases 

II 


10:30 

HANDS-ON 



1:30 

CMS III 

(Experienced) 


2: 30 

CP Commeinds 

II 


3:30 

Other RT&E Software (IMSL, CSMP, 

(Intermediate 



LARSYSPl, ...) 



3: 30 

HANDS-ON 



THURSDAY 

8:30 

EXEC II 

(Experienced) 

December 13 

9: 30 

Batch II 

•1 


10: 30 

EDIT 11 (Macros) 

If 


10:30 

HANDS-On 



1:30 

Graphics Programming 

(Intermediate) 


2:30 

LARSPEC 

II 


4:00 

HANDS-ON 



FRIDAY 

9:00 

Script 


(Intermediate) 

December 14 

9:00 

and 11:00 

LARSPEC Demonstration 



9:00 

- 2:00 pm 

General Consulting in the 

(Everyone) 


Remote Terminal Area 


